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

Tobias Looker tobias.looker at mattr.global
Fri Jun 5 01:12:48 UTC 2020


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.

-- 
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/20200605/bc6a3ad6/attachment.html>


More information about the Openid-specs-ab mailing list