Add subject_identifier_types_supported property to AS Metadata

[acoburn]

Resolves #151

This defines a new property for the authorization server metadata document: subject_identifier_types_supported. (Other, previously considered terms included: subject_uri_schemes_supported, subject_uri_resolvers_supported).

Inclusion of the new property is set at SHOULD level. If omitted, the default value is ["https"]

---

Preview | Diff

[elf-pavlik]

@acoburn could you explain shortly your thinking behind SHOULD instead of MUST and the default https? My general preference is to keep as much as possible explicit, I mostly want to understand motivation for the proposed approach.

[acoburn]

@elf-pavlik

Each of the authentication suites defines a validation section with text along the lines of

For an ID Token to validate as an LWS authentication credential, there must be a trust relationship between the verifier and the issuing party.

In the absence of a pre-existing trust relationship, the validator MUST dereference the sub (subject) claim in the authentication credential. The resulting resource MUST be formatted as a valid controlled identifier document [CID-1.0] with an id value equal to the subject identifier.

In other words, the AS either has a pre-existing trust relationship with the issuer (common in enterprise federations) or it doesn't (common in an open ecosystem deployment). Dereferencing the subject URI is therefore only necessary in the second case, meaning that there are entire categories of deployments in which the subject_uri_schemes_supported metadata is not relevant. That is why the property is optional.

In RFC 8414, many of the optional properties have defaults, and there seemed to be general support for making that default "https".

[TallTed]

It seems these should have <dfn> markup?

[acoburn]

@elf-pavlik suggested that, for DID identifiers, a scheme would be insufficient. In those cases, we would need both a scheme and method, as already suggested in the examples. E.g., did:web

[acoburn]

In order to support DID methods such as did:web, the use of "schemes" in subject_uri_schemes_supported is not quite accurate. Better terminology here may be "resolvers", since that's what is relevant, i.e.: subject_uri_resolvers_supported

[uvdsl]

Better terminology here may be "resolvers", since that's what is relevant, i.e.: subject_uri_resolvers_supported

I do see the issue with using "schemes" given the strict URI definition, but subject_uri_resolvers_supported reads a bit odd.

Naming it after "resolvers" makes it sound like the AS is advertising an internal software component rather than a protocol element. Usually, iirc, parameters describe what the AS accepts or produces, rather than the processor required to handle it.

Resolver/resolution is also an overloaded term as it might refer to act of retrieving the CID document, looking up the domain name for an IP address, or translating the URI string into a URI of a different scheme to further work with that.

Would maybe something like a generic subject_identifier_types_supported work better here?
That would also mirror subject_token_types_supported, which I find also to be a nice side-effect.

[acoburn]

@uvdsl thank you for that suggestion. I find subject_identifier_types_supported to be an improvement over the current proposal.

[acoburn]

The metadata term has been changed to subject_identifier_types_supported. I have updated the title and description of this PR to align with this change.

[TallTed]

Suggested change

	<dfn><code>subject_identifier_types_supported</code></dfn>
	OPTIONAL. JSON array containing a list of subject identifier types that the authorization server supports.
	Each value is a URI scheme such as <code>"https"</code> or, for Decentralized Identifiers,
	a <code>"did:"</code> prefix followed by the DID method name (e.g. <code>"did:web"</code>, <code>"did:key"</code>).
	An authorization server SHOULD advertise the subject identifier types
	<dfn><code>subject_identifier_types_supported</code></dfn>
	OPTIONAL. JSON array containing a list of subject identifier types that the authorization server supports.
	Each value is a URI starting with its scheme such as <code>"https:"</code>, or, for Decentralized Identifiers,
	<code>"did:"</code> followed by the DID method name (e.g., <code>"did:web"</code>, <code>"did:key"</code>).
	An authorization server SHOULD advertise the subject identifier types

[termontwouter]

While I agree with the need for this metadata, and the phrasing, I have two questions:

1. Given that we wanted to keep authorization concerns orthogonal to our specification, isn't this the wrong place to require such specific metadata from the AS?

2. There exist already a number of ways to list this kind of information; for example RFC 9493's Identifier Formats (used in GNAP's sub_id_formats_supported metadata), OIDC Discovery's subject_types_supported ... Is there any reason we're adding yet another one, instead of reusing one of these?

(The latter point also holds for the token types field, which could potentially be aligned with RFC 8693's Subject/Actor Token Types, OIDC IDA's Evidence Types, GNAP's assertion_formats_supported, OIDC Discovery's claim_types_supported ...)

[elf-pavlik]

https://www.rfc-editor.org/rfc/rfc9493.html#name-decentralized-identifier-di

The Decentralized Identifier (DID) Format identifies a subject using a DID URL as defined in [DID]. Subject Identifiers in this format MUST contain a "url" member whose value is a DID URL for the DID Subject being identified. The value of the "url" member MUST be a valid DID URL and MAY be a bare DID. The "url" member is REQUIRED and MUST NOT be null or empty. The Decentralized Identifier Format is identified by the name "did".

How can we advertise a method?

https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata

subject_types_supported
REQUIRED. JSON array containing a list of the Subject Identifier types that this OP supports. Valid types include pairwise and public.

https://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes

8. Subject Identifier Types
   A Subject Identifier is a locally unique and never reassigned identifier within the Issuer for the End-User, which is intended to be consumed by the Client. Two Subject Identifier types are defined by this specification:

public
This provides the same sub (subject) value to all Clients. It is the default if the provider has no subject_types_supported element in its discovery document.

pairwise
This provides a different sub value to each Client, so as not to enable Clients to correlate the End-User's activities without permission.

The OpenID Provider's Discovery document MUST list its supported Subject Identifier types in the subject_types_supported element. If there is more than one type listed in the array, the Client MAY elect to provide its preferred identifier type using the subject_type parameter during Registration.

I don't think we could reuse this one.