[Openid-specs-ab] SIOP Scope proposal

nadalin at prodigy.net nadalin at prodigy.net
Wed Dec 9 00:18:34 UTC 2020


I don’t think that #4 is in scope as this seed to be dealing with authentication downstream, so this is “reauthentication”, which will require enough material to be able to reauthenticate. This may also be a problem with holder binding. I think that “key” rollover might be in scope but in discussions #4 goes well beyond key rollover.

 

I’m still thinking about #5 Is your definition of Credential Presentation the following ? 

 

A credential presentation expresses data from one or more  credentials and it’s put in a way that the authorship of each credential element is verifiable. The information in a presentation is usually about the same subject, but issued by multiple issuers

 

From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> On Behalf Of Tobias Looker via Openid-specs-ab
Sent: Sunday, December 6, 2020 3:10 PM
To: David Waite <david at alkaline-solutions.com>
Cc: Tobias Looker <tobias.looker at mattr.global>; Artifact Binding/Connect Working Group <openid-specs-ab at lists.openid.net>
Subject: Re: [Openid-specs-ab] SIOP Scope proposal

 

Hi David,

 

Appreciate the feedback.

 

> 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.

 

Yes I think we agree, what I would like to see as a solution to this is how any OpenID Provider (whether they be in the form of a SIOP or not) could introduce the feature of portable subject identifiers, ideally I'd like to see the solution to this fit within the existing core protocol as much as possible, so reusing the id_token where we can.

 

> 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.

 

Yes I can see that argument, however to me the meaning of a SIOP has become a little muddled and what I think these 5 scopes attempt to begin to answer is, what is an SIOP and how is it different to an ordinary OP? In my simplified view all we really have is providers and the properties of those providers are a function of what features they choose to implement and the deployment model they appear as (e.g as a HTTP Server vs a PWA or Native app).

 

> 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.

 

Agreed, I like the terminology you have used to further classify this problem.

 

> 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.

 

I wouldn't say, "does not work" as an absolute (i.e there is no solution), but i'd agree our current strategies or solutions do not solve for SIOP.

 

> 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.

 

Yeap 100% agree.

 

> 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.

 

This is a great input into the work required for scopes 4. and 5.

 

Thanks,


 <https://mattr.global/> 

 


Tobias Looker


Mattr


+64 (0) 27 378 0461
 <mailto:tobias.looker at mattr.global> tobias.looker at mattr.global



 <https://mattr.global/> 

 <https://www.linkedin.com/company/mattrglobal> 

 <https://twitter.com/mattrglobal> 

 <https://github.com/mattrglobal> 


This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.

 

 

On Fri, Dec 4, 2020 at 6:58 PM David Waite <david at alkaline-solutions.com <mailto:david at alkaline-solutions.com> > wrote:

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

 





This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20201208/54b9602c/attachment-0001.html>


More information about the Openid-specs-ab mailing list