SIOP and Subject Resolving Identifiers

[David Waite]

I propose a simplification of SIOP and DID usage, where the subject (sub) is either a JWK thumbprint or a URI which is considered a "subject resolving identifiers".

An “subject resolving identifier” uses a trusted process, to authoritatively resolve associated key material \(JWKS\) for a subject based on a given URI and scheme.

This definition is purposely meant to create a resolution process which is abstract to DID-based resolution as well as other potential schemes like WebFinger and SOLID.

If this resolution process is defined as an API, one would expect it to look similar to:

func requestSubjectKeys(subject: URI) -> (jwks: JSON)

Specifically:

1. The key material needs to be defined as a JWKS to support signing the id_token, which is a JOSE-based construct needing algorithms defined according to JWA.
2. Because data is not given in a way where authority and integrity can be independently confirmed, this is necessarily a trusted process/component.

The metadata for an RP or OP would be expected to include information on resolvable identifier schemes supported. The resolution schemes SHOULD have a prefix of the URI method, but may have further distinguishing data (such as a DID method, as these each require different resolution implementations).

[Tom Jones]

this is actually a duplicate of several issues over the past year. The point of a sub is to find the keying materiel. If is is not a simple number (a hash?) then is must be a url.

[Kristina Yasuda]

Tom, currently sub is only jwkthumbprint or DID. To make SIOP v2 more extensible, I would agree we need to define an “abstract“ sub resolution mechanism, as long as it is well-defined and does not open attack surface.

DW, would it be possible to work on a concrete text either in this issue or in a PR?

[Tom Jones]

well we have another model - the PODS model from Tim BL

[David Waite]

@tomcjones one goal would be to have the WebID/SOLID-OIDC needs encapsulated here too, however I do not want to pretend I have a good grasp on all of their requirements (as my knowledge comes from spec reviews, not discussions).

@kristina I was planning to work on PRs with proposed text for my recent issues with this one last. As Tom mentioned, there have been several proposals around DID auth and portable identifiers, and I wanted to encourage discussion first to make sure this proposal meets stakeholder requirements.

[David Waite]

See also: #1261, #1209

[Kristina Yasuda]

I am not sure we would want to generalizing to incorporate “potential“ options. I believe having several concrete options like the two we do now (JWK Thumbprint and DID) is simpler and more implementable. DIDs are defined in DID-CORE and I don’t think OIDF should define a general mechanism in SIOP spec that abstracts DID-based resolution. If we need to clarify that a public key obtained from a DID Doc in SIOP has to be defined as JWKS, we could do it.

@Dmitri Zagidulin Does SOLID have a need to define a URI of a cryptographically resolvable identifier in SIOP in addition to JWK thumbprint/DIDs? I assume such URI scheme have a resolution mechanism defined?

[Kristina Yasuda]

At 2021-11-17 SIOP call DW agreed to write up a concrete text for a "subject resolving identifier" that is more generic than DIDs. WG agreed that we would not want to redefine DID resolution.

[Tom Jones]

I think you mean KERI, no? Wait - that is just a did method? I don't think there is any meaningful restriction to "did method" anymore.

Be the change you want to see in the world ..tom

[David Waite]

We have effectively accomplished this in SIOPv2, with backing text on using JWK Thumbprint URI and DIDs as subject identifiers.