<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<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 class="newpage" 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; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 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 class="newpage" 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; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 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"
cite="mid:CAJmmfSQHRsRPfxTGBoa6aoLeb8JS35tbOWMYd+o6iyz2hTs5iQ@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">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 class="moz-txt-link-freetext" href="https://mattrglobal.github.io/oidc-client-bound-assertions-spec/">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 class="moz-txt-link-freetext" href="https://tools.ietf.org/html/draft-fett-oauth-dpop-00">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 class="moz-txt-link-rfc2396E" href="https://mattr.global"><https://mattr.global></a>
*Tobias Looker*
Mattr
+64 (0) 27 378 0461
<a class="moz-txt-link-abbreviated" href="mailto:tobias.looker@mattr.global">tobias.looker@mattr.global</a>
[image: Mattr website] <a class="moz-txt-link-rfc2396E" href="https://mattr.global"><https://mattr.global></a> [image: Mattr on LinkedIn]
<a class="moz-txt-link-rfc2396E" href="https://www.linkedin.com/company/mattrglobal"><https://www.linkedin.com/company/mattrglobal></a> [image: Mattr on Twitter]
<a class="moz-txt-link-rfc2396E" href="https://twitter.com/mattrglobal"><https://twitter.com/mattrglobal></a> [image: Mattr on Github]
<a class="moz-txt-link-rfc2396E" href="https://github.com/mattrglobal"><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 class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Openid-specs-ab mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
<br>
</body>
</html>