Determine best way of managing identifiers

[Mark Haine]

In the “Predefined values” section there is reference to the use of a document in the eKYC Wiki for sharing pre-defined values with other parties

We should consider a more controlled document or even the creation of an iana registry for the values involved

[Mark Haine]

Don Thibeau has put an agenda item for OIDF board discussion

[Nat Sakimura]

We have discussed this in the Feb. 18 Board meeting.

While we have in the past had a registry operated by OIDF itself, the board’s current preference is to use IANA registry if it can.

The board is interested to learn the concerns of the WG around using the IANA registry, e.g., inflexibility, structure, etc., if any. This will feed into the board’s decision.

[Mark Haine]

RFC 7519 - JSON Web Token (JWT) Section 10 provides for the JWT claim registry managed by IANA.

It also mentions in Section 2 “Terminology” “Collision-Resistant Name” and allows for various methods to achieve collision resistance specifically:

• Domain Names
• OIDs under ITU-T X.660
• UUIDs (RFC 4122 - A Universally Unique IDentifier (UUID) URN Namespace)

This is all aimed at avoiding collisions in claim names causing interoperability issues and customisation of implementations

The requirements I have found for naming of various objects in the context of the eKYC & IDA Working group are as follows:

Claim names (both structured objects and simple key value pairs)

• globally relevant (e.g. nationalities or salutation)
• relevant to a single implementation (e.g. MarkBank_customer_number)
• scheme or domain specific claim names (e.g. eu eori_code or uk national insurance number)

eKYC specific values (these are not claim names and are currently maintained in a wiki page on OIDF eKYC & IDA Bitbucket)

• Trust Framework identifiers
• Identity document types
• Verification methods

The cases that it seems should be managed yet don’t seem to fit well with the options provided for in RFC 7519 are:

• the registration of specific standardised claim values

• scheme or domain specific claim names

  • Local schemes, trust frameworks or jurisdictions should be able to manage claim names locally without increasing the administrative load on the JWT claims experts in a way that permits their claims to be collision-resistant and registered

Using a DNS prefix would be good but in a number of instances there may not be a suitable “shared” dns registration that can realistically be used for a scheme or other domain

Naming of claims using either ITU-T X660 or UUIDs would seem to cause difficulties for human readers in troubleshooting or auditing cases and neither option really meets the goal of the JWT specification to be compact.

UUID as URN Example: urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
ITU-T X660 Example (ASN.1 notation): {itu-t(0) identified-organization(4) etsi(0) electronic-signature-standard(1733) attributes(2) 3}
ITU-T X660 Example (dot notation): 0.4.0.1733.2.3
ITU-T X660 Example (OID-IRI notation): /ITU-T/Identified-Organization/0/1733/2/3

[Nat Sakimura]

What about this?

• register claim names at IANA.
• create a JSON schema etc. for the allowable values and publish it as a spec at openid.net?

‌

[Mark Haine]

I have concerns about that being sufficiently scalable fo rthe various international schemes that may emerge. Once OpenID for IDA is at final there won’t be an obvious mechanism for schemes to register new claim names. Yet the schemes will need to have somewhere to register claim names that are peculiar to their use cases.

For values again it doesn’t seem scalable for multiple international schemes. Also does OpenID want to be the governance body for everyones registered values? That would seem like quite an admin task that isn’t really about the mechanics of the protocol.

I know that OIX are looking at this and the gov.uk Department for Culture Media and Sport are both looking at this area of attribute names and values and if there isn’t an obvious international solution then I expect there will be fragmentation.

I would argue that there should be a more hierarchical model created (perhaps the ability to register prefixes for schemes to then administer their own local claim/attribute names and values.

We should discuss this more.

[Mark Haine]

after discussions arising from issue #1309 the proposal is to address this by creating an oidf.net page that links to the non-normative references of the following types:

[verified_claims_request.json]

[verified_claims.json]

[predefined_values_page]

This will give us time to establish better registries or other locations to refer to without having to modify the references in the OIDC4IDA spec

[Mark Haine]

Links to comments in Issue #1309

[Joseph Heenan]

There was discussions on today’s call that an IANA registry may not be flexible enough as there was a desire to be able to create new entries without needing to create new specifications that add those entries. I just wanted to note that the IANA registries are pretty flexible and it is permitted for a registry to choose to use other policies; it’s covered here: https://www.rfc-editor.org/rfc/rfc8126.html#section-4

[Mark Haine]

new page added to oidf.net… https://openid.net/wg/ekyc-ida/references/

will create PR to divert the JSON Schema and predefined values there

[Mark Haine]

Having looked into this further it seems that we have two quite different requirements here:

1. the reference for predefined_values - it is normative - currently uses a redirect on openid.net and is fit for purpose today. I have opened a query about how we might change that redirect in the future if we wish to.
2. the reference for JSON schema files - non-normative, seems to be served direct from openid.net and would be better served with an intersticial page like the one that has been added here

I shall raise a PR to change the JSON schema references to the intersticial page. I suggest we don’t change the predefined values reference just now.

‌

[Mark Haine]

Resolved by PR #130