[Openid-specs-ab] Client Bound End-User Assertions

Tobias Looker tobias.looker at mattr.global
Mon Jun 8 04:57:18 UTC 2020


Thanks George, appreciate the feedback.

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?

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.

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?

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 Sat, Jun 6, 2020 at 7:55 AM George Fletcher <gffletch at aol.com> wrote:

> Thanks for the pointer to the spec!
>
> A couple comments...
>
> 1. Scopes are not order dependent per RFC 6749
>
>    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.
>
> 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
>
>
> On 6/4/20 9:12 PM, Tobias Looker via Openid-specs-ab wrote:
>
> 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.
> https://mattrglobal.github.io/oidc-client-bound-assertions-spec/
>
> 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 (https://tools.ietf.org/html/draft-fett-oauth-dpop-00).
>
> 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] <https://mattr.global> <https://mattr.global>
> *Tobias Looker*
> Mattr
> +64 (0) 27 378 0461tobias.looker at mattr.global
> [image: Mattr website] <https://mattr.global> <https://mattr.global> [image: Mattr on LinkedIn]<https://www.linkedin.com/company/mattrglobal> <https://www.linkedin.com/company/mattrglobal> [image: Mattr on Twitter]<https://twitter.com/mattrglobal> <https://twitter.com/mattrglobal> [image: Mattr on Github]<https://github.com/mattrglobal> <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.
>
>
>
> _______________________________________________
> Openid-specs-ab mailing listOpenid-specs-ab at lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>

-- 
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/20200608/baa27c30/attachment.html>


More information about the Openid-specs-ab mailing list