[Openid-specs-ab] SIOP Scope proposal

Tobias Looker tobias.looker at mattr.global
Wed Dec 9 03:24:05 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.

My impression of what is in scope for this point is perhaps different to
yours, fundamentally I think we have to add some form of extension to the
core OpenID Connect protocol so a request for a credential can be made and
to allow for things like cryptographic material to be included in the
request when the credential is going to feature a cryptographic binding to
the holder such is the case in verifiable credentials.

> 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

Yes fundamentally I think this scope item can be summarized as how does a
relying party make a request to a provider (a holder) requesting
presentation of claims that the provider is not the authority of, e.g the
holder is just "holding" and helping to facilitate presentation of the
claims to relying parties. Also what is the response syntax for presenting
claims from multiple authorities/"claims providers". I see a lot of
intersection in this scope item with the current aggregated and distributed
claims draft.

Thanks,
[image: Mattr website] <https://mattr.global>
*Tobias Looker*
Mattr
+64 (0) 27 378 0461
tobias.looker at mattr.global
[image: Mattr website] <https://mattr.global> [image: Mattr on LinkedIn]
<https://www.linkedin.com/company/mattrglobal> [image: Mattr on Twitter]
<https://twitter.com/mattrglobal> [image: Mattr on Github]
<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 Wed, Dec 9, 2020 at 1:18 PM <nadalin at prodigy.net> wrote:

> 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,
>
> [image: Mattr website] <https://mattr.global/>
>
>
>
> *Tobias Looker*
>
> Mattr
>
> +64 (0) 27 378 0461
> tobias.looker at mattr.global
>
> [image: Mattr website] <https://mattr.global/>
>
> [image: Mattr on LinkedIn] <https://www.linkedin.com/company/mattrglobal>
>
> [image: Mattr on Twitter] <https://twitter.com/mattrglobal>
>
> [image: Mattr on Github] <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>
> 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.
>
>

-- 
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/20201209/4e159df4/attachment.html>


More information about the Openid-specs-ab mailing list