<div dir="ltr">> 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.<div><br></div><div>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.<br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><br></div><div dir="ltr">> 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</div><div dir="ltr"><br></div><div>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.</div><div dir="ltr"> </div><div dir="ltr">Thanks,<br><table width="auto" cellpadding="0" cellspacing="0" border="0" style="color:rgb(0,0,0);font-family:Times;font-size:medium;border:0px"><tbody><tr style="font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:11px;line-height:16px"><td width="125" valign="top"><a href="https://mattr.global" style="border:none;color:rgb(15,173,225)" target="_blank"><img src="https://mattr.global/assets/images/MattrLogo.png" alt="Mattr website" width="125" height="125" style="height:auto"></a></td><td width="16"> </td><td width="159" valign="top" style="color:rgb(51,49,50);font-size:12px"><table cellpadding="0" cellspacing="0" border="0" style="border:0px"><tbody><tr style="font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:11px;line-height:16px"><td><strong style="font-size:12px">Tobias Looker</strong><br></td></tr><tr style="font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:11px;line-height:16px"><td style="line-height:16px">Mattr</td></tr><tr style="font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:11px;line-height:16px"><td style="line-height:16px;padding-top:12px">+64 (0) 27 378 0461<br><a href="mailto:tobias.looker@mattr.global" style="border:none;color:rgb(51,49,50)" target="_blank">tobias.looker@mattr.global</a></td></tr><tr style="font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:11px;line-height:16px"><td style="font-size:12px;padding-top:12px"><table cellpadding="0" cellspacing="0" border="0" style="border:0px"><tbody><tr style="font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:11px;line-height:16px"><td width="40"><a href="https://mattr.global" style="border:none;color:rgb(51,49,50);margin-right:12px" target="_blank"><img src="https://mattr.global/assets/images/website.png" alt="Mattr website" width="24" style="border:0px;height:40px;width:24px"></a></td><td width="40"><a href="https://www.linkedin.com/company/mattrglobal" style="border:none;color:rgb(51,49,50);margin-right:12px" target="_blank"><img src="https://mattr.global/assets/images/linkedin.png" alt="Mattr on LinkedIn" width="24" style="border:0px;height:40px;width:24px"></a></td><td width="40"><a href="https://twitter.com/mattrglobal" style="border:none;color:rgb(51,49,50);margin-right:12px" target="_blank"><img src="https://mattr.global/assets/images/twitter.png" alt="Mattr on Twitter" width="24" style="border:0px;height:40px;width:24px"></a></td><td width="40"><a href="https://github.com/mattrglobal" style="border:none;color:rgb(51,49,50);margin-right:12px" target="_blank"><img src="https://mattr.global/assets/images/github.png" alt="Mattr on Github" width="24" style="border:0px;height:40px;width:24px"></a></td></tr></tbody></table></td></tr></tbody></table></td></tr></tbody></table><br style="color:rgb(0,0,0);font-family:Times;font-size:medium"><small style="color:rgb(118,118,118);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:8px;line-height:14px">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.</small><br></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 9, 2020 at 1:18 PM <<a href="mailto:nadalin@prodigy.net">nadalin@prodigy.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US" style="overflow-wrap: break-word;"><div class="gmail-m_2099533056375199393WordSection1"><p class="MsoNormal">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.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">I’m still thinking about #5 Is your definition of Credential Presentation the following ? <u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">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<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in"><p class="MsoNormal"><b>From:</b> Openid-specs-ab <<a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank">openid-specs-ab-bounces@lists.openid.net</a>> <b>On Behalf Of </b>Tobias Looker via Openid-specs-ab<br><b>Sent:</b> Sunday, December 6, 2020 3:10 PM<br><b>To:</b> David Waite <<a href="mailto:david@alkaline-solutions.com" target="_blank">david@alkaline-solutions.com</a>><br><b>Cc:</b> Tobias Looker <tobias.looker@mattr.global>; Artifact Binding/Connect Working Group <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>><br><b>Subject:</b> Re: [Openid-specs-ab] SIOP Scope proposal<u></u><u></u></p></div><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal">Hi David,<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Appreciate the feedback.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><p class="MsoNormal">> 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.<u></u><u></u></p><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">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.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">> 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.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">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).<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">> 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.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Agreed, I like the terminology you have used to further classify this problem.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">> 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.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">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.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">> 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.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Yeap 100% agree.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">> <a href="https://dwaite.github.io/multipass/draft-waite-multipass-retrieval.html" target="_blank">Multipass Container Retrieval</a> 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.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">This is a great input into the work required for scopes 4. and 5.<u></u><u></u></p></div><div><div><div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Thanks,<u></u><u></u></p><table border="0" cellspacing="0" cellpadding="0"><tbody><tr><td width="125" valign="top" style="width:93.75pt;padding:0in"><p class="MsoNormal" style="line-height:12pt"><a href="https://mattr.global/" target="_blank"><span style="font-size:8.5pt;font-family:Helvetica,sans-serif;color:rgb(15,173,225);border:1pt none windowtext;padding:0in;text-decoration:none"><img border="0" width="125" height="125" style="width: 1.2986in; height: 1.2986in;" id="gmail-m_2099533056375199393_x0000_i1029" src="https://mattr.global/assets/images/MattrLogo.png" alt="Mattr website"></span></a><span style="font-size:8.5pt;font-family:Helvetica,sans-serif;color:black"><u></u><u></u></span></p></td><td width="16" style="width:12pt;padding:0in"><p class="MsoNormal" style="line-height:12pt"><span style="font-size:8.5pt;font-family:Helvetica,sans-serif;color:black"> <u></u><u></u></span></p></td><td width="159" valign="top" style="width:119.25pt;padding:0in"><table border="0" cellspacing="0" cellpadding="0"><tbody><tr><td style="padding:0in"><p class="MsoNormal" style="line-height:12pt"><strong><span style="font-size:9pt;font-family:Helvetica,sans-serif">Tobias Looker</span></strong><span style="font-size:8.5pt;font-family:Helvetica,sans-serif"><u></u><u></u></span></p></td></tr><tr><td style="padding:0in"><p class="MsoNormal" style="line-height:12pt"><span style="font-size:8.5pt;font-family:Helvetica,sans-serif">Mattr<u></u><u></u></span></p></td></tr><tr><td style="padding:9pt 0in 0in"><p class="MsoNormal" style="line-height:12pt"><span style="font-size:8.5pt;font-family:Helvetica,sans-serif">+64 (0) 27 378 0461<br><a href="mailto:tobias.looker@mattr.global" target="_blank"><span style="color:rgb(51,49,50);border:1pt none windowtext;padding:0in">tobias.looker@mattr.global</span></a><u></u><u></u></span></p></td></tr><tr><td style="padding:9pt 0in 0in"><table border="0" cellspacing="0" cellpadding="0"><tbody><tr><td width="40" style="width:30pt;padding:0in"><p class="MsoNormal" style="line-height:12pt"><a href="https://mattr.global/" target="_blank"><span style="font-size:8.5pt;font-family:Helvetica,sans-serif;color:rgb(51,49,50);border:1pt none windowtext;padding:0in;text-decoration:none"><img border="0" width="24" height="40" style="width: 0.25in; height: 0.4166in;" id="gmail-m_2099533056375199393_x0000_i1028" src="https://mattr.global/assets/images/website.png" alt="Mattr website"></span></a><span style="font-size:8.5pt;font-family:Helvetica,sans-serif"><u></u><u></u></span></p></td><td width="40" style="width:30pt;padding:0in"><p class="MsoNormal" style="line-height:12pt"><a href="https://www.linkedin.com/company/mattrglobal" target="_blank"><span style="font-size:8.5pt;font-family:Helvetica,sans-serif;color:rgb(51,49,50);border:1pt none windowtext;padding:0in;text-decoration:none"><img border="0" width="24" height="40" style="width: 0.25in; height: 0.4166in;" id="gmail-m_2099533056375199393_x0000_i1027" src="https://mattr.global/assets/images/linkedin.png" alt="Mattr on LinkedIn"></span></a><span style="font-size:8.5pt;font-family:Helvetica,sans-serif"><u></u><u></u></span></p></td><td width="40" style="width:30pt;padding:0in"><p class="MsoNormal" style="line-height:12pt"><a href="https://twitter.com/mattrglobal" target="_blank"><span style="font-size:8.5pt;font-family:Helvetica,sans-serif;color:rgb(51,49,50);border:1pt none windowtext;padding:0in;text-decoration:none"><img border="0" width="24" height="40" style="width: 0.25in; height: 0.4166in;" id="gmail-m_2099533056375199393_x0000_i1026" src="https://mattr.global/assets/images/twitter.png" alt="Mattr on Twitter"></span></a><span style="font-size:8.5pt;font-family:Helvetica,sans-serif"><u></u><u></u></span></p></td><td width="40" style="width:30pt;padding:0in"><p class="MsoNormal" style="line-height:12pt"><a href="https://github.com/mattrglobal" target="_blank"><span style="font-size:8.5pt;font-family:Helvetica,sans-serif;color:rgb(51,49,50);border:1pt none windowtext;padding:0in;text-decoration:none"><img border="0" width="24" height="40" style="width: 0.25in; height: 0.4166in;" id="gmail-m_2099533056375199393_x0000_i1025" src="https://mattr.global/assets/images/github.png" alt="Mattr on Github"></span></a><span style="font-size:8.5pt;font-family:Helvetica,sans-serif"><u></u><u></u></span></p></td></tr></tbody></table></td></tr></tbody></table></td></tr></tbody></table><p class="MsoNormal"><span style="font-size:13.5pt;font-family:Times,serif;color:black"><br></span><span style="font-size:6pt;font-family:Helvetica,sans-serif;color:rgb(118,118,118)">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.</span><u></u><u></u></p></div></div></div><p class="MsoNormal"><u></u> <u></u></p></div></div><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal">On Fri, Dec 4, 2020 at 6:58 PM David Waite <<a href="mailto:david@alkaline-solutions.com" target="_blank">david@alkaline-solutions.com</a>> wrote:<u></u><u></u></p></div><blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in"><div><div><p class="MsoNormal">Hello Tobias! I agree with the proposal to break apart SIOP into component pieces.<u></u><u></u></p></div><div><p class="MsoNormal"><br><br><u></u><u></u></p><blockquote style="margin-top:5pt;margin-bottom:5pt"><div><div><div><p class="MsoNormal">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.<u></u><u></u></p></div></div></div></blockquote><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">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.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">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.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><blockquote style="margin-top:5pt;margin-bottom:5pt"><div><div><div><p class="MsoNormal">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.<u></u><u></u></p></div></div></div></blockquote><div><div><blockquote style="margin-top:5pt;margin-bottom:5pt"><div><div><p class="MsoNormal">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.<u></u><u></u></p></div></div></blockquote><div><div><div><p class="MsoNormal"><u></u> <u></u></p></div></div></div></div></div><div><p class="MsoNormal">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.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">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.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div></div><div><blockquote style="margin-top:5pt;margin-bottom:5pt"><div><div><div><p class="MsoNormal">4. Credential Issuance support - Issuing credentials from OpenID Connect flows.<u></u><u></u></p></div><div><p class="MsoNormal">5. Credential Presentation support - Presenting credentials in OpenID Connect flows.<u></u><u></u></p></div></div></div></blockquote><div><p class="MsoNormal"><u></u> <u></u></p></div><p class="MsoNormal">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.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"><a href="https://dwaite.github.io/multipass/draft-waite-multipass-retrieval.html" target="_blank">Multipass Container Retrieval</a> 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.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">-DW<u></u><u></u></p></div><p class="MsoNormal"><u></u> <u></u></p></div></blockquote></div><p class="MsoNormal"><br><br><u></u><u></u></p><pre style="background:white"><span style="font-size:10.5pt;color:black">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.</span><span style="font-size:10.5pt"><u></u><u></u></span></pre></div></div></blockquote></div>

<br>
<pre style="font-family:"Courier New",Courier,monospace,arial,sans-serif;margin-top:0px;margin-bottom:0px;white-space:pre-wrap;background-color:rgb(255,255,255);font-size:14px">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.</pre>