Subject: [Txauth] XAuth-01

From: Dick Hardt <[email-masked]>
Date: Wed, 29 Jan 2020 23:06:35 -0800

For some reason, the IETF links for draft-hardt-xauth are broken in the
data tracker, but are working in ietf tools.

The latest version is still up at
https://tools.ietf.org/id/draft-hardt-xauth-protocol-00.html

But the 01 submission is stuck.

You can see it here:

https://dickhardt.github.io/hardt-xauth-protocol/draft-hardt-xauth-protocol.html

See the changelog for changes.

The big change is letting the Client ask the AS to authenticate the User,
and then return those results while the AS is still interacting with the
User. The Client can then look up the User, and decide what identity claims
and/or authorizations to request from the User, if any.

The Client can then make another request for that information, or for
nothing.

New Users, or Users that have not provided the latest set of information,
are prompted to release it, and the results are returned to the Client.
Existing Users that have provided everything are not prompted.

The sequence is a little more complicated, but looks to me like it solves
the issue that Justin brought up in his critique.

/Dick
ᐧ

---

From: Justin Richer <[email-masked]>
Date: Thu, 30 Jan 2020 08:56:29 +0100

Thanks for this iteration. I think this is a much more complicated approach than having a token-protected user information API, though.

 — Justin

> On Jan 30, 2020, at 8:06 AM, Dick Hardt <[email-masked]> wrote:
> 
> For some reason, the IETF links for draft-hardt-xauth are broken in the data tracker, but are working in ietf tools.
> 
> The latest version is still up at https://tools.ietf.org/id/draft-hardt-xauth-protocol-00.html <https://tools.ietf.org/id/draft-hardt-xauth-protocol-00.html>
> 
> https://dickhardt.github.io/hardt-xauth-protocol/draft-hardt-xauth-protocol.html <https://dickhardt.github.io/hardt-xauth-protocol/draft-hardt-xauth-protocol.html>
> 
> The big change is letting the Client ask the AS to authenticate the User, and then return those results while the AS is still interacting with the User. The Client can then look up the User, and decide what identity claims and/or authorizations to request from the User, if any.
> 
> The Client can then make another request for that information, or for nothing.
> 
> New Users, or Users that have not provided the latest set of information, are prompted to release it, and the results are returned to the Client. Existing Users that have provided everything are not prompted.
> 
> The sequence is a little more complicated, but looks to me like it solves the issue that Justin brought up in his critique.
> 
> 
> /Dick
> ᐧ
> -- 
> Txauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth

---

From: Dick Hardt <[email-masked]>
Date: Thu, 30 Jan 2020 11:50:13 -0800

The authentication first feature solves a different, but related problem
than the token-protected user information API. It deals how to minimize
when user consent is requested.

Either the AS prompts for release of claims and authorizations on each
request, or the AS must remember which claims where released to which
Client for each User. If the AS is used for authentication, the user
experience of constantly being prompted is poor, so many implementations
remember what was previously released, and make it available at the user
info endpoint, because the AS does not know if the Client wants to fetch
the data again. From a privacy point of view, making the AS remember which
Clients received which claims is a burden on the AS. A compromise of the AS
exposes a User's history across the all Clients.

Additionally, the AS must deal with the User changing or deleting their
information. Does the AS provide the new data without consent? Does it
continue to provide an API to data the User has deleted? The implementation
details at the AS are pretty complicated.

Perhaps I am missing something, but the user info API allows a Client to
decide if it when it wants to fetch data. It ALWAYS has access to the data.

Since we now have a communication link between the Client and the AS  *while
the User is at the AS*, the Client can dynamically determine what
information it needs.

I'm *NOT* suggesting we should support authentication first, I was just
sharing an insight that it was possible now.

It does complicate the protocol, but it can simplify Client and AS
implementations as it brings an implementation issue into the protocol. It
also makes it crisp when data between the Client and AS is shared, without
prompting the User each time.

/Dick

On Wed, Jan 29, 2020 at 11:56 PM Justin Richer <[email-masked]> wrote:

> Thanks for this iteration. I think this is a much more complicated
> approach than having a token-protected user information API, though.
>
>  — Justin
>