How does RP determine sub type?

[Torsten Lodderstedt]

RPs can register for different sub types (jkt, did) and multiple did methods. It is unclear to me how the RP determines the sub type used in a particular ID token.

[Kristina Yasuda]

What has been discussed is

• using OpenID Federation style entity statements for RP to look up which sub type SIOP uses

• using SIOP Chooser (Issue #1212), where RP knows subject_identifier_types_supported of a SIOP set to which a particularSIP instance belongs to

However, even then, if entity statement or a SIOP set says that a SIOP instance supports both, there is still no way for a RP to determine which subject identifier type is used in a particular ID token.

Should an additional parameter subject_identifier_type_used be included in the response for RP to know?

[Torsten Lodderstedt]

I think the sub type must be part of the ID token.

[Michael Jones]

We’re previously talked about having the SIOP V2 sub values be URIs, so that their type is self-describing. We could create a JWK Thumbprint URN specification in IETF for the case where the subject refers to a key.

[Alen Horvat]

RP should be able to determine the sub type. See my last comment in https://bitbucket.org/openid/connect/issues/1262/example-of-did-based-sub

If it doesn’t solve the issue → Both approaches (URI or sub_type param) are future proof. How complex is to create JWK Thumbprint URN specification in IETF?

[Kristina Yasuda]

on 2021-07-08 call, two approaches were discussed: 1/ add new metadata property to ID Token that explicitly allows RP to identify which sub type is used 2/ use URIs in sub so that RP can determine the type based on that URI

[Kristina Yasuda]

to describe the way the relying party determines subject_identifier_type as part of the ID token validation

[Kristina Yasuda]

Re-assigning to Mike to create JWK thumbprint URN specification

[David Waite]

I’ll see if I can post some napkin math, but we may wish to forego a jwk thumbprint uri and instead have a jwk uri outright.

Size wise: There’s a balance between the growth from having large scalars b64 encoded twice vs including a thumbprint.

Simplicity wise: the creator of the URI is responsible for keeping it consistent as an identifier. You don’t need JWK thumbprints, which not all JWS libs expose

[Kristina Yasuda]

why jwk instead of jwk thumbprint?

[David Waite]

With a thumbprint, you need to send the actual key as well.

[Kristina Yasuda]

Currently, if subject syntax type is did, sub=did:<method name>:<identifier> and sub_jwk is omitted; if subject syntax type is jwk, sub_jwk is present. the RP would look at sub syntax and the presence/absence of sub_jwk. Does this makes sense? Is this sufficient from the RP perspective?

PS I added the text clarifying this in PR #68

[Kristina Yasuda]

Resolved with the introduction of JWK thumbprint URI (currently individual draft status in IETF) and hte following text in the ID Token Verification section

The RP MUST identify which Subject Syntax Type is used based on the URI of the sub Claim. Valid values defined in this specification are urn:ietf:params:oauth:jwk-thumbprint for JWK Thumbprint Subject Syntax Type and did: for Decentralized Identifier Subject Syntax Type.