Subject: [Txauth] Client bound user assertions

From: Tobias Looker <[email-masked]>
Date: Fri, 20 Mar 2020 11:22:35 +1300

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.

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.

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,
 <https://mattr.global>
*Tobias Looker*
Mattr
+64 (0) 27 378 0461
[email-masked]
 <https://mattr.global> 
<https://www.linkedin.com/company/mattrglobal> 
<https://twitter.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.

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

---

From: Dick Hardt <[email-masked]>
Date: Fri, 20 Mar 2020 12:48:02 -0700

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 <[email-masked]>
wrote:

> 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,
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth
>

---

From: Tobias Looker <[email-masked]>
Date: Sat, 21 Mar 2020 10:31:43 +1300

Hi Dick,

Yes that's correct.

Thanks,
Tobias

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

>> This communication, including any attachments, is confidential. If you
>> are not the intended recipient, you should not read it - please contact me

---

From: Justin Richer <[email-masked]>
Date: Sat, 21 Mar 2020 13:00:08 -0400

Hi Tobias,

I think this is a new pattern that we’re going to be seeing more of, with smart clients and credential wallets enabling things with mobile devices that we couldn’t do before. 

One of the first things we built into XYZ was the ability to pass and receive assertions between the client and the AS in both directions. In addition to the client being able to get an assertion about a user (like in OIDC), it was an important feature that the client be able to present an assertion back to the AS itself, so that the AS can make an access determination without bugging the user, in the right circumstances. I think what you’re proposing here is an interesting and valid extension of that. 

The assertions in OIDC are really designed to primarily be one-time messages to the client from the AS. This is fantastic for logging in to the client as an app, but the ID token really wasn’t meant to go beyond that. I think that the structure of things like VCs,, with presentation proofs through different keys and the like, is a powerful pattern that we can enable in TxAuth. 

I agree with Dick that there are a few missing pieces, like instructions for how an AS can bind the client’s presented key to an assertion, that can be facilitated. I am not convinced that solving those within the TxAuth working group is the right approach — I think this is a part of the larger field of identity that would be better solved by a dedicated group. 

 — Justin

> On Mar 19, 2020, at 6:22 PM, Tobias Looker <[email-masked]> 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.
> 
> Here the client obtains a user assertion from the OP or Authorization server that is suitably bound to the client in an authenticatable way.
> 
> <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.
> 
> <Screen Shot 2020-03-12 at 10.05.20 AM.png>
>  
> 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.
> 
> 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,
>  <https://mattr.global/>	 	
> Tobias Looker
> Mattr
> +64 (0) 27 378 0461
> [email-masked] <mailto:[email-masked]>
>  <https://mattr.global/>	 <https://www.linkedin.com/company/mattrglobal>	 <https://twitter.com/mattrglobal>	 <https://github.com/mattrglobal>