[Openid-specs-ab] SIOP Scope proposal

Tobias Looker tobias.looker at mattr.global
Sun Dec 6 23:09:52 UTC 2020


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20201207/328b5896/attachment.html>


More information about the Openid-specs-ab mailing list