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

George Fletcher gffletch at aol.com
Fri Jun 5 19:55:16 UTC 2020

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>
> *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.
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20200605/88264f5c/attachment.html>

More information about the Openid-specs-ab mailing list