DID resolver method for OIDC Federation

[Giuseppe De Marco]

In SIOPv2 “6. Discovery and Registration” we read
”””
If client_id is a HTTPS URL, client_id is resolved to obtain all Relying Party metadata from an Entity Statement as defined in [OpenID.Federation].
”””

I propose to have an OIDC Federation resolution method instead, eg:

did:openid:example.it:oidc:rp that resolves to https://example.it/oidc/rp/.well-known/openid-federation

The resolution method could be defined in OIDC Federation and referenced in did-spec-registries.

even the sections “9.2.2.1. OpenID Federation 1.0 Automatic Registration” and “9.2. Non-Pre-Registered Relying Party” would be renewed by this proposal.

[Giuseppe De Marco]

Other specs, like OIDC4VP and OIDC4VCI would not receive any modification, being all delegated to the method of resolution of the did, that it would include from now on also oidc federation between those recognizable.

[Torsten Lodderstedt]

I would like to understand the difference between the current way OIDC Federation works and your proposal:

OIDC Federation: The entity id “https://example.it/oidc/rp” can be used as client_id. In that case the OP (or SIOP) appends “.well-known/openid-federation” to the client id and and retrieves the entity configuration from “https://example.it/oidc/rp/.well-known/openid-federation”.

did:openid: The client is “did:openid:example.it:oidc:rp“. This did is transformed into the entity id “https://example.it/oidc/rp”. Afterwards, “.well-known/openid-federation” is appended and the entity configuration from “https://example.it/oidc/rp/.well-known/openid-federation”.

Is that correct?

[Giuseppe De Marco]

@Torsten Lodderstedt yes it is, thank you for having explained it very well

[Giuseppe De Marco]

• There is a need to clarify what we would achieve by replacing http URL with DIDs as a mechanism to obtain Entity Statements in OpenID Federation

when I thought of proposing did:openid I didn’t even think of replacing https url within the specific OIDC Federation or its current implementations.

The idea of getting did:openid was born from the following needs

1. Have a clear and well recognizable namespace in SSI context and id wallet, for did identifiers that can be resolved to a OpenID Federation
2. Simplify the reading of the SIOPv2 specification that currently introduces OIDC Federation with an "IF" rather than a did resolver that points to OIDC fed and whose definition would be better to be left to the did method registers. I think that did:openid is best presented in the wallet context, SSI and web3 in general
3. Improve the comprehensibility. A URL is self-referential, obtaining it in an entity statement is a consolidated fact, obtaining it rather in a verifiable credential or presentation requires an implementor to be in possession of important assumptions about the existence of openid federation. did:openid is more explicit and completely equivalent to a URL
4. It represents a first step for OIDC Fed to enter in the world of ledgers and with some unique peculiarities. OIDC Fed is not flat (as ledgers actually are) and above all is not centralized, inwhen an entity can be resolved at more than one trust anchor simultaneously, then join multiple trust frameworks and policy simultaneously, depending on the context in which it is placed and resolved. This is a unique property of this technology and being able to represent it through a different format would allow it to expand its audience, reach more people, and exclusively changing a dress without introducing breaks with the past or critical changes of the current specification.

In a nutshell we could say that a subject or a public key can be trusted with oidc federation and that the representation of an Issuer within a VC/VP can be done with did:openid

I feel reluctant to have did:openid within the values of the sub and iss claims of entity statements and trust marks, let me be clear. did:openid would be exclusively an interface for a world, an external dimension, with which we can find a point of contact

[Michael Jones]

As I wrote on today’s SIOP Special Topic Call, defining a DID resolution method and making it mandatory to implement seems to me like taking something that’s currently simple and making it unnecessarily complex. I sincerely believe that OpenID Connect succeeded, in part, because we kept simple things simple. Let’s stay the course on that!

Yes, we do have a dependence on DIDs in the SIOP V2 spec, but use of DIDs is opt-in - not required. You only have to have support for the kinds of DIDs used by SIOPs you choose to use. Let’s keep it that way.

I believe this issue should be closed with no action.

[Kristina Yasuda]

Discussed in 2022-Mar-31 SIOP call, WG members are encouraged to continue discussion in the Issue to clarify what we can achieve with this solution.

[Kristina Yasuda]

(Probably better to classify this as Federation related issue since this SIOP only uses Entity Statements as defined in the Federation specification.)

[Giuseppe De Marco]

Just my two points:

1. I really don’t want to make did:openid as mandatory, it won’t affect any aspect of OIDC Federation, it would only be an interface from the SSI world to OpenID Fed

2. A URL doesn’t means OpenID Connect Federation and an implementer should try to find it through a .well-known paths. Instead did:openid is more explicit than a URL, it is a clear pointer to a clear specification

Having said this I do not cultivate any particular expectation for this issue that I consider completely "cosmetic" for openid, no regret on my part to close it here

[Torsten Lodderstedt]

Improve the comprehensibility. A URL is self-referential, obtaining it in an entity statement is a consolidated fact, obtaining it rather in a verifiable credential or presentation requires an implementor to be in possession of important assumptions about the existence of openid federation. did:openid is more explicit and completely equivalent to a URL

I personally like the self descriptive nature of did:openid in comparison of just another URL that is used as an entity identifier.

[Kristina Yasuda]

resolving did:openid:example.it:oidc:rp into https://example.it/oidc/rp/.well-known/openid-federation is not enough to qualify as a new DID method. DID Document compliant to DID-CORE specification would need to be hosted at https://example.it/oidc/rp/.well-known/openid-federation. DID Doc != Entity Statement. This is where I see interoperability problems. It’s not just about introducing an abstraction layer, but defining a new Entity Statement format.

[Giuseppe De Marco]

I Agree @kristina

It works for establishing trust between parties under a common federation. Regarding the Need to have a diddoc in a entity statement we May adopt some interoperability compromises or define new claims but we must be sure that's worth It and It doesnt seem so

[Giuseppe De Marco]

Anyway, is not required that a did method resolves to a DIDDocument.
For example the did key method just give a public key

at the same time did:openid offers a way to fetch a publick keys (fed jwks) and a way to resolve the trust

[Michael Jones]

The prevailing sentiment seems to be against adding this. I propose closing this on that basis, possibly during tomorrow’s working group call.

[Giuseppe De Marco]

Ok, I close it reluctantly. I will always carry did:openid in my heart!

:'-)