Re: [Txauth] Client bound user assertions

[Tobias Looker <[e-mail]>]

Hi Dick,

Yes that's correct.

Thanks,
Tobias


On Sat, 21 Mar 2020, 08:48 Dick Hardt, <[e-mail]> wrote:

> Hi Tobias
>
> Let me see if I understand the end goal.
>
> The Client presents a assertion about the user created by the AS, when
> their are interacting with to a relying party.
>
> Correct?
>
> There are a number of ways to solve this, but in my opinion, creating the
> missing features for this to be done would be in scope of TxAuth.
>
>
>
> On Thu, Mar 19, 2020 at 3:23 PM Tobias Looker <[e-mail]>
> wrote:
>
>> Hi,
>>
>> I'm unsure of the best way to articulate this idea on this forum, but see
>> my below explanation for an attempt. I'm also aware that it as a discussion
>> topic is dependent on how "identity" fits into TxAuth in general.
>>
>> With OpenID connect today the format of the user assertions we get are
>> often bound to the client (or a small audience) mainly by the issuer using
>> the audience field in the id_token to communicate who it is for (e.g this
>> is for client x) which gives all parties a way to determine whether they
>> are the intended audience of the assertion. However, this does not enable a
>> client to authenticate as the intended audience of the user assertion to
>> other parties. If a client was instead able to authenticate as the rightful
>> audience of a user assertion then they would be able to onward disclose the
>> user assertion to a relying party, such that the relying party would be
>> able to authenticate both the original issuer of the assertion and the
>> client now presenting the assertion.
>>
>> See below for a simple example.
>>
>> Here the client obtains a user assertion from the OP or Authorization
>> server that is suitably bound to the client in an authenticatable way.
>>
>> [image: Screen Shot 2020-03-12 at 10.05.15 AM.png]
>>
>> The relying party now makes a request to the client who is in possession
>> of the assertion from the authorization server and the client can respond,
>> presenting the assertion. In this flow, with regards to OIDC, the client is
>> essentially taking a similar role to that of a self issued openid connect
>> provider.
>>
>> [image: Screen Shot 2020-03-12 at 10.05.20 AM.png]
>>
>> How this could be realized in TxnAuth?
>>
>> If the client strongly authenticates at the start of an authorization
>> transaction e.g by signing the original authorization request with either
>> an ephemeral or static key, the resulting assertion could be bound to this
>> key enabling the client to authenticate as the rightful audience of the
>> assertion to other relying parties. Similar to how DPOP for access_tokens
>> works.
>>
>> Why is this interesting and what use cases does it enable?
>>
>> Being able to obtain user assertions that can be bound to the client such
>> that the client can onward disclose them enables new opportunities around
>> how users can manage different sources of their identity information
>> through a single client. This can help to eliminate things like the nascar
>> problem and presentations to relying parties that require aggregating
>> assertions from multiple authorization servers.
>>
>> Thanks,
>> [image: Mattr website] <https://mattr.global>
>> *Tobias Looker*
>> Mattr
>> [phone]
>> [e-mail]
>> [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.
>>
>> --
>> Txauth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/txauth
>>
>

-- 
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.