Extensibility: how do we support extensibility for trust frameworks, evidence types, verification methods and id documents?

[Torsten Lodderstedt]

Can we setup IANA registries?

[Michael Jones]

Some Connect specs use IANA registries - which can only be created by RFCs. For instance, we created the OAuth Authorization Server Metadata registry https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#authorization-server-metadata well after we created OpenID Connect Discovery. We registered the metadata values once the registry was created.

In other cases, the OpenID specs define parameters and some initial values but say that other values can be defined by other specs. For instance, the Subject Identifier Types defined at https://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes use this model.

[Nat Sakimura]

more description needed.

[Michael Jones]

We typically query for supported features via the Discovery metadata. We should do that. Documents can define values even if they aren’t put in a registry.

[Torsten Lodderstedt]

Tony talks to Mike and finds out how we could utilize IANA registries

[Marcos Sanz]

Regardless of where the repository for the official lists of these 4 elements is:

• Should we officially support in the spec “private” values? (like Core does for Additional Claims in Section 5.1.2)

And we need some text on how RPs should deal with unknown values (this is reciprocal direction to issue https://bitbucket.org/openid/ekyc-ida/issues/1094/how-to-treat-unknown-identifiers-in-claims):

• In section 4.1 we already state “RPs SHOULD ignore verified_claims containing a trust framework id they don’t understand” (which is a fine strategy by me)

• In Section 4.1.1.1 and with regard to evidence/document/type we state “The OP MAY use other than the predefined values in which case the RPs will either be unable to process the assertion, just store this value for audit purposes, or apply bespoken business logic to it”, but I think this text is too descriptive and not normative enough. I’d go for “RPs SHOULD ignore document types they don’t understand”.

• There’s no guidance at the moment for unknown evidence/type or evidence/method. We have to deal with that.

‌

[Vladimir Dzhuvinov]

Marcos: What do you refer to when you say “private [registry] values”? Extensions not “sanctioned” by this WG?

Another thought: Require extensions to publish a JSON schema.

[Marcos Sanz]

Re “Private values”: Yes. A space to experiment, with the recommendation to use collision-resistant names by e.g. prefixing them with URIs.

Re “JSON schema”: Good point. Since the content of “verification” element is completely dependant on the value of “trust_framework” in the registry, each new “trust_framework” should be accompanied by a formal definition of the “verification” structure.

[Torsten Lodderstedt]

Tony suggested to use namespaces instead of registries. We can set up a web page to list the know identifiers. We need to decide what the best representation will be: HTML, md, … wiki.

[Torsten Lodderstedt]

Nahiro will make the first stab for the page.

[Torsten Lodderstedt]

link in the spec should be stable, Link to openid.net is better suited than Bitbucket reference. Torsten will check options and provide Naohiro with URL.

[Torsten Lodderstedt]

PR was merged