Proposal: credential type superseding

[sietseringers]

We propose to make it possible for a credential type to be superseded by another credential type. This can be used in the following cases:

• When a credential type migrates to a new issuer,
• When a credential type has to be modified in a way that would invalidate existing credential instances, for example when an attribute needs to be removed.

This proposal makes the superseded credential type and the credential type that succeeds it fully equivalent: when either one is requested in a session, then either credential types satisfies it.

Scheme

Using the following two tags in the credential type XML:

<IssueSpecification version="4">
  <SchemeManager>pbdf</SchemeManager>
  <IssuerID>pbdf</IssuerID>
  <CredentialID>mobilenumber</CredentialID>

  <SupersededBy>pbdf.sidn-pbdf.mobilenumber</SupersededBy>
  <SupersededSince>1636326000</SupersededSince>

  <!-- ... -->

</IssueSpecification>

This indicates that the current credential type will be superseded by pbdf.sidn-pbdf.mobilenumber as of Unix timestamp 1636326000 (Mon Nov 08 2021 00:00:00 GMT+0100).

The SupersededBy is required. The SupersededSince tag is optional; if absent then SupersededBy takes effect immediately.

Behaviour

The SupersededBy tag in a credential type enables the following behaviour from the date onwards specified in SupersededSince:

Suppose the credential type scheme1.issuer1.cred1 superseeds or is superseded by the credential type scheme2.issuer2.cred2. If the requestor requests an attribute called scheme1.issuer1.cred1.attr while scheme2.issuer2.cred2.attr also exists, and the app sends scheme2.issuer2.cred2.attr, then the verifier will accept it.

This means that the app should offer both scheme1.issuer1.cred1.attr and scheme2.issuer2.cred2.attr as candidates to the user to choose from, and the user is free to choose either one.

Notice that when a client supporting this feature performs a session with a verifier that does not support this feature, in which a superseded or superseding credential is requested, the client can end up sending an attribute that the verifier does not accept. Therefore, this feature requires a new IRMA protocol version to ensure that it only activates when both the client and requestor support it.

Backwards compatibility

In case of a migration from one credential type to another such as from pbdf.pbdf.mobilenumber to pbdf.sidn-pbdf.mobilenumber, the requestor can either update its IRMA server to one supporting this functionality, or update its session request. Therefore, we need only consider the case of an old app performing sessions with new IRMA servers.

Suppose again that the credential type scheme1.issuer1.cred1 superseeds or is superseded by the credential type scheme2.issuer2.cred2, and suppose that an updated IRMA server performs a session with an old app in which scheme1.issuer1.cred1.attr is requested.

That is, if the session request is schematically of the following form:

{
  "@context": "https://irma.app/ld/request/disclosure/v2",
  "disclose": [
    [
      [
        "scheme1.issuer1.cred1.attr",
        "schemeX.issuerX.credX.attrX",
      ],
      // other conjunctions
    ],
    // other disjunctions
  ]
}

In this case, the requestor knows it can expect either scheme1.issuer1.cred1.attr or scheme2.issuer2.cred2.attr. We can convey these options to the (old) app by using the following expanded session request:

{
  "@context": "https://irma.app/ld/request/disclosure/v2",
  "disclose": [
    [
      [
        "scheme1.issuer1.cred1.attr",
        "schemeX.issuerX.credX.attrX",
      ],
      [
        "scheme2.issuer2.cred2.attr",
        "schemeX.issuerX.credX.attrX",
      ],
      // other conjunctions
    ],
    // other disjunctions
  ]
}

That is, when the client retrieves the IRMA session request from the server during the session, the server replies with the above. In the client, this results in the same behaviour as when it would have supported the feature.

Motivation

In the past, a number of credential types have had to migrate from one issuer to another:

• The email and mobilenumber credential types of the pbdf.pbdf issuer have migrated to pbdf.sidn-pbdf;
• The personalData and address credential types of the pbdf.nijmegen issuer have migrated to sidn.gemeente.

Additionally, in the future the idin, ideal and surfnet credential types of the pbdf.pbdf issuer will have to migrate as well to pbdf.sidn-pbdf.

To perform such migrations, we previously had to create transition windows in which requestors had to update their session request. Some time after that, the requestor also needs to remove the old credential types from its session request. This puts strain on the requestors as well as on the issuer, which needs to time the transition carefully. Additionally, if someone forgets something or makes a mistake in this process, IRMA app users can end up in problematic scenarios. This proposal aims to solve all of this, by making the transition automatic based on the Superseded XML tags.