[Openid-specs-ab] SIOP Scope proposal

David Waite david at alkaline-solutions.com
Fri Dec 4 05:58:42 UTC 2020


Hello Tobias! I agree with the proposal to break apart SIOP into component pieces.

> 1. Enabling portable subject identifiers between providers - Define how to use techniques such as asymmetric cryptography and higher level technologies like Decentralized Identifiers to create subject identifiers that are not intrinsically bound to a particular OP and hence can be ported between providers.

Agreed. It is certainly possible for a cryptographic proof of ownership of a portable identifier to be made by a different party than a traditional hosted OP. For a hybrid case where we are using portable identifiers with traditional connect providers, we should consider that we may get both a traditional issuer-scoped subject and a portable identifier. I’m still in favor of this being a different credential, which also gives a chance of evolving to different forms of identifier proofs.

I think I could argue successfully that tokens issued today via SIOP, while named “id_token”, are not compatible with the processing or trust model of an id_token issued by a known/hosted issuer. We have an opportunity to actually treat this as a different animal now, and not categorize cryptographically asserted identifiers as being equivalent to the public/pairwise/transient identifiers which are issuer asserted and scoped.

> 2. Solving for provider discovery and registration - Evaluating solutions to problems like the nascar problem, how does an RP come to have a relationship with an OP or understand its capabilities along with what role the user plays in this selection/discovery process.
> 3. RP - OP co-location on the same device - Dealing with the unique requirements that are brought about when the OP the RP is communicating with is on the same device (e.g in the form of a PWA or Native App), rather than a traditional Authorization server.

The approaches here usually categorize into provider determination (tell me where to go) or mediation (I’m going to send you my request, get it to the right place). The determination approaches (such as a NASCAR screen and manual selection) do not really impact protocol, but real mediation (such as CHAPI or openid:// URL registrations) have an effect both on protocol and on the security properties of the transport - and requires substantial considerations.

Of course, there are cases like local self-issued providers where determination does not work, and future envisioned browser/platform-level support will likely take a mediation approach. I’m just saying that this has often been done on a case-by-case basis in the past, and some new work here (GNAP) has taken a harder line at the protocol requiring a hosted provider/HTTPS transport.

> 4. Credential Issuance support - Issuing credentials from OpenID Connect flows.
> 5. Credential Presentation support - Presenting credentials in OpenID Connect flows.

This is perhaps what I’m most excited about. I hope we have the ability to make credential presentation look like normal openid connect in a minimal case, and enable both existing OPs to present more types of credentials and allow for a web-hosted wallet “upgrade” to a native experience based on universal links.

Multipass Container Retrieval <https://dwaite.github.io/multipass/draft-waite-multipass-retrieval.html> contains some rough work at the idea of credential issuance using OIDC and OAuth - an access token authorizes the user agent to request tokens be issued via a REST call. I could see this being input toward issuance support once it has its own pass at decoupling.

-DW

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20201203/255ff44a/attachment.html>


More information about the Openid-specs-ab mailing list