Subject: [Txauth] Fwd: New Version Notification for draft-hardt-xauth-protocol-05.txt

From: Dick Hardt <[email-masked]>
Date: Sat, 7 Mar 2020 19:16:56 -0800

Please forgive, and point out inconsistencies! If anything is confusing,
please let me know. It is likely a mistake on my part!

   1. I'm proposing there are only 2 types of interactions defined: a
   redirect interaction where the Client can redirect to the GS, and the GS
   back to the Client; or an indirect interaction where the User somehow gets
   to the GS, and there is no redirect back to the Client. The security
   characteristics are different, as session fixation can be prevented if the
   GS redirects back to the Client as the Client is able to verify the User it
   is interacting with is the same as the User the GS is interacting with.
   2. I added a sequence where the Client does a PATCH on the Grant URI
   with an interaction nonce received from the GS in the redirect back to the
   Client to protect against fixation attacks.
   3. The Authorization lifecycle and management is now independent of the
   Grant. A Client now receives an access token, OR an AuthZ URI. Reading and
   refreshing an access token are the same thing.

A more complete list of changes is below:
draft-hardt-xauth-protocol-05

   - separated claims from identifiers in request user object
   <http://localhost:8080/#section-a.6-1.1>
   - simplified reciprocal grant flow
   <http://localhost:8080/#section-a.6-1.2>
   - reduced interactions to redirect and indirect
   <http://localhost:8080/#section-a.6-1.3>
   - simplified interaction parameters
   <http://localhost:8080/#section-a.6-1.4>
   - added in language for Client to verify interaction completion
   <http://localhost:8080/#section-a.6-1.5>
   - added Verify Grant API and Interaction Nonce
   <http://localhost:8080/#section-a.6-1.6>
   - replaced Refresh AuthZ with Read AuthZ. Read and refresh are same
   operation.

---------- Forwarded message ---------
From: <[email-masked]>
Date: Sat, Mar 7, 2020 at 7:08 PM
Subject: New Version Notification for draft-hardt-xauth-protocol-05.txt
To: Dick Hardt <[email-masked]>

A new version of I-D, draft-hardt-xauth-protocol-05.txt
has been successfully submitted by Dick Hardt and posted to the
IETF repository.

Name:           draft-hardt-xauth-protocol
Revision:       05
Title:          The XAuth Protocol
Document date:  2020-03-07
Group:          Individual Submission
Pages:          59
URL:
https://www.ietf.org/internet-drafts/draft-hardt-xauth-protocol-05.txt
Status:         https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol/
Htmlized:       https://tools.ietf.org/html/draft-hardt-xauth-protocol-05
Htmlized:
https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protocol
Diff:
https://www.ietf.org/rfcdiff?url2=draft-hardt-xauth-protocol-05

Abstract:
   Client software often desires resources or identity claims that are
   independent of the client.  This protocol allows a user and/or
   resource owner to delegate resource authorization and/or release of
   identity claims to a server.  Client software can then request access
   to resources and/or identity claims by calling the server.  The
   server acquires consent and authorization from the user and/or
   resource owner if required, and then returns to the client software
   the authorization and identity claims that were approved.  This
   protocol can be extended to support alternative authorizations,
   claims, interactions, and client authentication mechanisms.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

ᐧ

---

From: Justin Richer <[email-masked]>
Date: Tue, 10 Mar 2020 09:58:27 -0400

The interaction structure mimics the two return styles in XYZ (which are switched on whether you provide a “callback” structure or not) but still doesn’t allow the client to specify different interaction mechanisms. It seems that now the GS needs to guess what the client is capable of. To me, one of our greatest opportunities here is moving away from the assumptions of web-based interaction. I believe we need to account for this in a way that’s more flexible than a single-type system. 

If I have a client app that could get the user to you in a browser or send you VC’s directly, I should be able to tell you that upfront and have the AS respond to any and all actions that it can do.

 — Justin

> On Mar 7, 2020, at 10:16 PM, Dick Hardt <[email-masked]> wrote:
> 
> Please forgive, and point out inconsistencies! If anything is confusing, please let me know. It is likely a mistake on my part!
> I'm proposing there are only 2 types of interactions defined: a redirect interaction where the Client can redirect to the GS, and the GS back to the Client; or an indirect interaction where the User somehow gets to the GS, and there is no redirect back to the Client. The security characteristics are different, as session fixation can be prevented if the GS redirects back to the Client as the Client is able to verify the User it is interacting with is the same as the User the GS is interacting with. 
> I added a sequence where the Client does a PATCH on the Grant URI with an interaction nonce received from the GS in the redirect back to the Client to protect against fixation attacks.
> The Authorization lifecycle and management is now independent of the Grant. A Client now receives an access token, OR an AuthZ URI. Reading and refreshing an access token are the same thing. 
> separated claims from identifiers in request user object <http://localhost:8080/#section-a.6-1.1>
> simplified reciprocal grant flow <http://localhost:8080/#section-a.6-1.2>
> reduced interactions to redirect and indirect <http://localhost:8080/#section-a.6-1.3>
> simplified interaction parameters <http://localhost:8080/#section-a.6-1.4>
> added in language for Client to verify interaction completion <http://localhost:8080/#section-a.6-1.5>
> added Verify Grant API and Interaction Nonce <http://localhost:8080/#section-a.6-1.6>
> replaced Refresh AuthZ with Read AuthZ.. Read and refresh are same operation.
> 
> From: <[email-masked] <mailto:[email-masked]>>
> To: Dick Hardt <[email-masked] <mailto:[email-masked]>>
> 
> 
> 
> URL:            https://www.ietf.org/internet-drafts/draft-hardt-xauth-protocol-05.txt <https://www.ietf.org/internet-drafts/draft-hardt-xauth-protocol-05.txt>
> Status:         https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol/ <https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol/>
> Htmlized:       https://tools.ietf.org/html/draft-hardt-xauth-protocol-05 <https://tools.ietf.org/html/draft-hardt-xauth-protocol-05>
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protocol <https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protocol>
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-hardt-xauth-protocol-05 <https://www.ietf.org/rfcdiff?url2=draft-hardt-xauth-protocol-05>
> 
> Abstract:
> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> 
> The IETF Secretariat
> 
> 
> ᐧ
> -- 
> Txauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth