Include supported CID resolution schemes in "5.2.2 Authorization Server Metadata"

[laurensdeb]

Currently there is no way for a client to detect what resolution mechanisms for agent identifiers are supported. It would probably be sensible to make this discoverable somehow. Given the agnostic nature of the subject_token_type identifiers and the authentication suites there currently is no machine readable source for this information.

[acoburn]

It seems that we will need an additional metadata field for the authorization server to indicate additional constraints or requirements. We may want to look at how OpenID Federation handles this for client entities.

[elf-pavlik]

I see client_id_metadata_document_supported but this one is HTTP
in https://www.ietf.org/archive/id/draft-ietf-oauth-client-id-metadata-document-02.html#name-oauth-authorization-server-

We may need to define something, I'm not sure if there is prior-art where AS has to advertise resolution capabilities. Maybe worth asking on DID mailing list?

OIDC Federation seems to expect https everywhere https://openid.net/specs/openid-federation-1_0.html#federation_entity

[elf-pavlik]

Resolving this issue, may be the major part of resolving

• Agent Identification #57 (comment)

[acoburn]

At present, we define the authorization metadata property subject_token_types_supported, expecting an array of URIs.

Some options for accounting for CID resolution schemes include:

1. Continue to use subject_token_types_supported, but expect a map of keys and values, where the keys are the same URIs used today and the corresponding values would be an array of supported CID schemes. For example:

{
  "subject_token_types_supported": {
    "urn:ietf:params:oauth:token-type:jwt": ["did:web", "did:key", "https"],
    "urn:ietf:params:oauth:token-type:id-token": ["https"]
  }
}

2. Keep subject_token_types_supported as-is, and introduce a second property called subject_formats_supported (or cid_formats_supported) that uses a map of URIs associated with supported subject/cid scheme prefixes:

{
  "subject_token_types_supported": [
    "urn:ietf:params:oauth:token-type:jwt",
    "urn:ietf:params:oauth:token-type:id-token"
  ],
  "subject_formats_supported": {
    "urn:ietf:params:oauth:token-type:jwt": {
      "url_schemes_supported": ["did:web", "did:key", "https"]
    },
    "urn:ietf:params:oauth:token-type:id-token": {
      "url_schemes_supported": ["https"]
    }
  }
}

While I like the compactness of option 1, I do find that option 2 is more explicit and (arguably) more consistent with other OAuth2 client metadata parameters currently registered with IANA. See, for instance, the vc_formats_supported, which is a structure that allows for potential expansion. I am not partial to the specific property names, if anyone has better suggestions.

Edit: changed cid_prefix_supported to url_schemes_supported

[uvdsl]

Might I suggest "url_scheme_supported" over "cid_prefix_supported"?

The CID spec uses that wording in 3.3 Retrieve Verification Method:

Let controllerDocument be the result of dereferencing controllerDocumentUrl, according to the rules of the URL scheme and using the supplied options.

[uvdsl]

Question:

• Do we need to distinguish between the token types for the subject url scheme support?
• Can we maybe simply have subject_url_scheme_supported with an array of values (supported for any token type)?

[acoburn]

subject_url_schemes_supported would be considerably simpler (I added an s to schemes, since that is the convention in the existing OAuth registrations). Distinguishing between different token types seems more like a theoretical use case. I would be inclined to keep this as simple as possible unless someone has a specific need for a more complex discovery mechanism.

Incorporating this revision would look like:

{
  "subject_token_types_supported": [
    "urn:ietf:params:oauth:token-type:jwt",
    "urn:ietf:params:oauth:token-type:id-token"
  ],
  "subject_url_schemes_supported": [
    "did:web", 
    "did:key", 
    "https"
  ]
}

A follow-on question would be: if subject_url_schemes_supported is omitted, should we indicate a default value of ["https"]?

[uvdsl]

A follow-on question would be: if subject_url_schemes_supported is omitted, should we indicate a default value of ["https"]?

Given that I proposed HTTPS as a baseline for interoperability, I would be in favor of having HTTPS as the default AND being able to advertise additionally supported Subject URL Schemes (just like in the above example). 👍

[elf-pavlik]

I support subject_url_schemes_supported,it seems orthogonal to specific token types and stands on its own as capability 👍
Would it make sense to add

LWS Server MUST support https and advertise it in server metadata's subject_url_schemes_supported.

I recall @laurensdeb was objecting somewhere to require https from all implementations/deployments, since some may go did:??? only

[uvdsl]

hiding this comment and moving it to #57 (comment) as it is derails the discussion here

I recall @laurensdeb was objecting somewhere to require https from all implementations/deployments, since some may go did:??? only

As far as I understood, the problem described in the comment you remember, @elf-pavlik, boils down to a registry problem to establish a governance federation of acceptable identifiers. Establishing such registry (trust anchor) can be solved by using did:customMethod resolves to a governed lookup service. And it can be solved as well by using federation approaches e.g. in the style of OpenID Federation 1.0 when using HTTPS identifiers. So the argument of "HTTPS identifiers scale poorly" does not hold. It is just the naive approach to using them that does not scale.

In addition, I recall @acoburn's comment that requiring an identifier scheme is problematic as that required scheme might not be used by existing enterprises. That is not the point of the baseline: Nobody needs to adopt HTTPS identifiers if they don't want to. You can use DIDs if you want. But an LWS AS must be able to authenticate HTTPS CIDs as a baseline for interoperability -- just like LWS AS must be able to offer OAuth token exchange. @acoburn said it himself in our F2F meeting:

Technically we are not mandating that everyone implement OAuth. We are making OAuth a baseline for interoperability

Same for my proposal for HTTPS CIDs being the baseline to be supported by an LWS AS (advertised e.g. via #227).