Resolving Client_ID

[David W Chadwick]

Concerning RP registration, this specification (section 6.3.2) defines two methods of resolving client_id of the RP to obtain RP's public key and metadata i.e. using a DID or using the hashed public key (https URI). However, neither method is mandatory. This means that we will end up with two disjoint un-interoperable worlds, one that uses DIDs and one that uses HTTPS URIs. It is suggested that HTTPS URIs are mandated and DIDs are optional, so as to ensure a minimal interoperable subset that all SIOP applications must implement.

‌

[Tom Jones]

This is an essential issue with the did core spec that i raised over 2 years ago. For whatever reason they decided that did interop would not depend on https - as it turns out that was a very poor decision. Anyway, the did is a URL in spite of what everyone actually codes, so the RP should be able to publish a https and did resolution endpoints. They may, or may not, be the same key. Therein lies a major challenge. The basic issue is that neither really is the real-world client. It also means that the user code may have one client id for the application level interchange and another, unrelated one, for the wallet interchange. The ability for the user to manage such a state of affairs is most limited. Also the various endpoints being discussed in openID core, openid federation, mDL and others make it unclear if these will wind up in the browser as first party or third party transaction. In the later case the user will soon be unable to use session creds across endpoints. Potentially FedCM could help, but only in limited scenarios.

‌

I suspect that the real solution is to have a real-word id for the client and several endpoints bound to it. As in Legend, each cliant are many.

[Kristina Yasuda]

The way OIDC addresses these kind of interoperability issues is by having registration and discovery mechanisms. and, in fact, we spent large portion of SIOP calls making sure registration and discovery in SIOP work well.

RP and OP will pre-agree whether they will use HTTP URI or DID. No need to mandate either.

[David W Chadwick]

This is exactly the right solution to solve the PE policy issue

[Tom Jones]

I just don’t get it. I am on a web site of an RP with https and a url that seems recognizable. I click a button to [[sign in]], The browser with the well know URL disappears and a new UX appears asking for lots of information about me. In the OIDC case that is from [[Google]] or some other social provider that i am very familiar with.

In the SIOP case what exactly is it that this “client” of mine is saying to me on the wallet that gives me the sense that this [[sign in]] is to the site to which i had naviaged? I presume it came from a client registration using a did that has no meaning to me. What does have meaning to a human user? What would cause me to release my private information to this supposed client of mine?

Here’s the problem - there is NO CONTINUITY - i am talking to a different endpoint with different software on the phone - what is it that connects one to the other.

[Kristina Yasuda]

Tom, below are the options for the registration in SIOP. David is talking about a choice between 2a and 2b (if I read correctly)

1. a pre-registered RP/Client - client_id is pre-registered

2. Not pre-registered RP/Client - client_id is NOT pre-registered

   1. DID that the Wallet/SIOP might be seeing for the first time; DID Doc used to obtain only the key to verify the signed request (if it is signed); rest of the registration metadata is included in the request itself
   2. HTTPS URL that the Wallet/SIOP might be seeing for the first time; Entity statement used to obtain the registration metadata AND the key to verify the signed request
   3. redirect_uri = client_id; request is not signed

‌

[Tom Jones]

Wearing my hat as a user, I am utterly baffled by all of this. If some cite claims to be chase bank with a certificate signed by the ibb international banking bamboozlers, how am I to decide to accept the connection?

Nothing about this passes any security smell test.

[David W Chadwick]

Kristina you are correct, thanks

[David W Chadwick]

Tom. “I just don’t get it. “ I agree with you that there is an issue in your point. I think it deserves a new issue to be raised by you for a separate discussion (I don't want to address it here). The current issue is not about the point that you are raising. Kristina has summarised nicely what the current issue is about.

[Kristina Yasuda]

I don’t believe we need to mandate any of the registration methods in the SIOP v2 specification. To use the analogy you might be more familiar with, David C., SIOP v2 itself is closer to 23220 series which are building blocks. Then for the concrete use-cases, trust frameworks (AAMVA, ISO 18013-5, etc.) can make a choice and mandate certain mechanisms in SIOP. I don’t think it’s SIOP v2’s goal to make sure all implementations of SIOP v2 absolutely work with each other (like 18013-5 tries to do) - use-cases SIOP v2 covers are a little broader than that.

[Kristina Yasuda]

Discussed during 2022-Feb-17 SIOP call and agreed to close this issue on the following grounds. We agreed that OIDC does not have mandatory registration mechanisms and SIOP does not need to mandate as well. We might come back to this topic once we have more SIOP implementations and one registration method emerges as dominant.