<div dir="ltr">Thanks George, appreciate the feedback.<div><br></div><div>R.e point 1, thanks I had skipped over that detail, I will investigate this a little more, essentially the intent of the scope was for the client to convey to the AS that it would like a bound assertion (e.g a credential) as the result. Similar to how the openid scope indicates the intent to get an assertion about the end-user (among other things). The other option is to append a new request parameter that communicates this intent instead?</div><div><br></div><div>R.e point 2, yes absolutely, I think this perhaps intersects with the claims aggregation endpoint that is currently being worked on? i.e if in the request made to this new endpoint a client could include proof of a binding mechanism (e.g proof of possession of a private key in the form of a digital signature) then the returned assertion could be bound to the client.</div><div><br></div><div>R.e point 3, I'm not an expert on this particular spec so maybe others can chime in, but because to date with the spec we have chosen to stick with the existing claims syntax that was set out by openid connect core (e.g we have just defined a new top level member in the claims object called "credential"), I believe it would work? However where I'm not sure is we are using the signed request object to make sure proof of the binding mechanism is established in the request, if this is not done then the AS doesn't know if the client has control over the binding mechanism it is going to use in the resulting assertion?<br clear="all"><div><div dir="ltr" data-smartmail="gmail_signature"><div dir="ltr"><br></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 Sat, Jun 6, 2020 at 7:55 AM George Fletcher <<a href="mailto:gffletch@aol.com" target="_blank">gffletch@aol.com</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>
    <font face="Helvetica, Arial, sans-serif">Thanks for the pointer to
      the spec!<br>
      <br>
      A couple comments...<br>
      <br>
      1. Scopes are not order dependent per RFC 6749<br>
    </font><br>
    <pre style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0);font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial">   The value of the scope parameter is expressed as a list of space-
   delimited, case-sensitive strings.  The strings are defined by the
   authorization server.  If the value contains multiple space-delimited
   strings, their order does not matter, and each string adds an
   additional access range to the requested scope.
<font face="Helvetica, Arial, sans-serif">
</font></pre>
    <pre style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0);font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial"><font face="Helvetica, Arial, sans-serif">2. I can see the need to obtain a credential after authorization that doesn't require 
    user consent because consent has already been given. Has any consideration 
    been given to a profile for token-exchange?

3. With the introduction of the Rich Authorization Request (RAR) spec, how does 
    that fit into the definition of claims requested to be returned in the credential?

Thanks,
George
</font></pre>
    <br>
    On 6/4/20 9:12 PM, Tobias Looker via Openid-specs-ab wrote:<br>
    <blockquote type="cite">
      <pre>Hi All,

I linked the following draft we have been working on in one of the
conversations around SIOP but instead wanted to start a separate
conversation about this spec in general.

<a href="https://mattrglobal.github.io/oidc-client-bound-assertions-spec/" target="_blank">https://mattrglobal.github.io/oidc-client-bound-assertions-spec/</a>

Essentially the high level overview of this spec is to extend OIDC to
support what we refer to as client bound end-user assertions. In OIDC
today, the primary output assertion format about the end-user is the
"id_token", however a client in receipt of an "id_token" as the product of
an OIDC flow, cannot really re-present this to another RP in a way in which
authenticates them as the rightful presenter of the assertion, because it
features no authenticatable binding. If instead the output assertion about
the end-user featured an authenticatable binding then we believe several
flows around SIOP become easier to accomplish and more robust. The way in
which we propose to achieve this binding is through public private key
cryptography, similar to how DPop for access tokens was defined (
<a href="https://tools.ietf.org/html/draft-fett-oauth-dpop-00" target="_blank">https://tools.ietf.org/html/draft-fett-oauth-dpop-00</a>).

Because of some constraints around "id_token" in open id core and a desire
to not create any breaking changes, we felt it was necessary to
distinguish with a new response element called a "credential" (which is the
term used to describe a client bound end-user assertion).

Another feature of this spec which we are interested in feedback from the
group on is around allowing the client to request the resulting assertion
format type. Obviously in OIDC today all assertions are based around JWT
which are a great simple assertion format, however in flows where there is
a layer of indirection added between the issuer of an assertion (OP) and
the relying party, such as in SIOP with aggregated claims, it is arguable
that the lack of support for formal semantic vocabularies (i.e that
technologies like JSON-LD provide) can constrain use cases.

Finally, some will be aware of the currently active effort around
decentralized identifiers at the W3C. We see this technology as being quite
useful in these flows as a DID can provide a layer of indirection in the
binding mechanism allowing the client to perform operations such as key
rotation without having to re-contact the issuer (OP) for a new assertion.

Thanks,
[image: Mattr website] <a href="https://mattr.global" target="_blank"><https://mattr.global></a>
*Tobias Looker*
Mattr
+64 (0) 27 378 0461
<a href="mailto:tobias.looker@mattr.global" target="_blank">tobias.looker@mattr.global</a>
[image: Mattr website] <a href="https://mattr.global" target="_blank"><https://mattr.global></a> [image: Mattr on LinkedIn]
<a href="https://www.linkedin.com/company/mattrglobal" target="_blank"><https://www.linkedin.com/company/mattrglobal></a> [image: Mattr on Twitter]
<a href="https://twitter.com/mattrglobal" target="_blank"><https://twitter.com/mattrglobal></a> [image: Mattr on Github]
<a href="https://github.com/mattrglobal" target="_blank"><https://github.com/mattrglobal></a>
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>
      <br>
      <fieldset></fieldset>
      <pre>_______________________________________________
Openid-specs-ab mailing list
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
    </blockquote>
    <br>
  </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>