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

Issue #1093 resolved
Torsten Lodderstedt created an issue

Can we setup IANA registries?

Comments (15)

  1. 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.

  2. 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.

  3. 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 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.

  4. 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.

  5. 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.

  6. Torsten Lodderstedt reporter

    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.

  7. Torsten Lodderstedt reporter

    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.

  8. Log in to comment