Subject: [Txauth] XAuth -02

From: Dick Hardt <[email-masked]>
Date: Fri, 7 Feb 2020 19:59:23 -0800

I've heavily revised XAuth again.

https://tools.ietf.org/html/draft-hardt-xauth-protocol-02

A number of new ideas to bounce around:

I have included a bunch of sequences to show different use cases possible.

Rather than a transaction, I use a Grant as the central object.

The interface is very RESTful.

The AS is now a Grant Server (GS)

This also seemed appropriate at it is both an OAuth AS, and an OIDC OP.

Rather than a handle, the Grant has a URI.

The endpoint URI for the GS is the GS URI, and is the GS identifier.

An access token, refresh token etc. are all an Authorization. An
Authorization has an AuthZ URI.

The Grant URI and AuthZ URI all start with the GS URI.

A Grant is created by doing a POST to the GS URI, returning a Grant URI.

Metadata for the GS is done with an OPTIONS to the GS URI.

The Client can do GET, UPDATE, and DELETE against a Grant URI.

An access token refresh is a GET on the AuthZ URI.

Adding in Reciprocal OAuth functionality was more straightforward than in
OAuth 2.0 -- but not as straight forward as I would like -- but not clear
how to make it better and start from the Client and GS having context of
one authorization before swapping roles.

Per my last emails, naming is hard, there are likely lots of mistakes, and
lots of aspects that need normative language. Hopefully the concepts come
through!

/Dick

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Mon, 10 Feb 2020 22:58:22 +0000

Interesting work. I am enjoying the fact that we have two different takes on the same problem. The comparisons and discussions will lead us to a better overall solution.

Here are my comments on XAuth-02:

Section 2.1:
   *  *Resource Owner* (RO) - owns the RS, and has delegated RS access
      management to the GS.  The RO may be the same entity as the User, ...

I’m rather baffled by this definition, and wondering if it’s a mistake or if I’m misinterpreting it. Is this an intentional departure from how “RO” is typically used within the OAuth 2.0 space? Usually the term RO refers to the entity that owns the specific resources the client is requesting authorization for. The RO does not typically own the RS itself.

Section 5.5.2:

   The interaction object contains the type of interaction the Client

   will provide the User.  Other attributes

<snip>

        -  *type* - contains one of the following values: "popup",

           "redirect", or "qrcode"....

3 issues with this:

  1.  How would I do a user code-based interaction?
  2.  Clients support multiple interaction modes and may not always know what the GS supports (and vice-versa). For a multi-tenant GS, it may vary by tenant configuration. Clients should be able to say what they can do, and the GS should be able to tell them which one to use. It’s a very simple but powerful inline negotiation.
  3.  I don’t see the value of the “popup” interaction mode. Clients can use “redirect” mode within popups. However, speaking as someone who has done that, I really don’t recommend it. Popups are increasingly unsupported, and prone to weird behavioral issues. In-app browsers in Facebook, Twitter, etc. tend to have popups disabled. The last versions of IE Mobile didn’t support them at all (the popped up page basically just loaded into the current window).

Section 12.6:

        [Editor: is there some other reason to have the UserInfo

        endpoint?]

I may want to host my UserInfo endpoint on a separate microservice from my token endpoint (in OAuth 2.0/OIDC terms). The former might be part of my user profile/directory stack, while the latter is part of the highly privileged authentication/authorization stack.

Section 12.8:

        *Why have both claims and authorizations?*

        There are use cases for each that are independent:

        authenticating a user vs granting access to a resource.  A

        request for an authorization returns an access token or handle,

        while a request for a claim returns the claim.

I don’t agree that the use cases are distinct. The only claim that is strictly necessary for authentication is the user identifier. Other claims like email and phone_number are often used to aid in local account identification (i.e., account linking), but are useful and interesting beyond this use case. Other claims such as name, preferred_username, and birthdate could be used in a similar fashion, though they frequently aren’t. The same is true for other resources not currently defined as claims (e.g., the externalId established when the user was imported through SCIM).

Claims are just resources that OIDC provides a name registry and some extra features for:

  *   Optionally get the value bundled with the authentication response, without needing to call a separate endpoint.
  *   Optionally get the value in a signed or encrypted blob.
  *   Optionally provide some structured metadata describing the resource and/or requested authorization.

It’s telling that all of these are optional. If we think these are features worth bringing forward into whatever protocol we produce through TxAuth, we should look at them independently of the claim/resource dichotomy.

Section 12.12:

        *Why complicate the sequence with "interaction"."keep"?*

I understand the use case you’re trying to support here, but I think the proposal is too complicated to implement. From the sequences, it looks like the Client is expected to issue a Read Grant request, and that connection will be kept open while the User is redirected to the GS and goes through the authentication workflow (and possibly part of the authorization workflow). Only then would the GS return the Read Grant response. Is this correct?

To implement this, the Client has to launch an asynchronous thread to execute that request and awaiting the response. Possible, but susceptible to failures. What happens if that thread crashes? Or fails to send the Update Grant request to flip interaction.keep to false? What is the GS doing in the meantime? Is it just showing the User a “loading” widget as it waits for the Client to update the grant? How long does it wait for? For mobile apps, that background thread may get killed or lose network connectivity as soon as the user gets switched over to the system browser to load the GS sign in page. For a pure-JS app that redirects, I don’t think this is possible at all. (unless web workers can survive page unloads?)

This is an interesting use case for us to think about, but it needs a lot of work and may not be something we should try to bake into the core protocol if we don’t need to.

Section 12.14:

        *Why use URIs to instead of handles for the Grant and

        Authorization?*

I didn’t like this until I realized that you’re distinguishing between handles/URIs and tokens. Now that I’ve thought about it more, I like this from the standpoint that it underscores the idea of Grants and Authorizations being persistent objects within the protocol. And it’s really just making public something that the GS is probably going to be doing under the hood anyway. However, we have to be careful that we don’t accidentally encourage implementers to start shoving things into these URIs.

–
Annabelle Backman (she/her)
AWS Identity
https://aws.amazon.com/identity/

From: Txauth <[email-masked]> on behalf of Dick Hardt <[email-masked]>
Date: Friday, February 7, 2020 at 8:00 PM
To: "[email-masked]" <[email-masked]>
Subject: [Txauth] XAuth -02

An access token, refresh token etc. are all an Authorization. An Authorization has an AuthZ URI..

Adding in Reciprocal OAuth functionality was more straightforward than in OAuth 2.0 -- but not as straight forward as I would like -- but not clear how to make it better and start from the Client and GS having context of one authorization before swapping roles.

Per my last emails, naming is hard, there are likely lots of mistakes, and lots of aspects that need normative language. Hopefully the concepts come through!

/Dick

---

From: Dick Hardt <[email-masked]>
Date: Wed, 12 Feb 2020 18:34:23 -0800

Thanks for the feedback Annabelle, sorry for the delay in responding.

Comments and questions inserted:

On Mon, Feb 10, 2020 at 3:38 PM Richard Backman, Annabelle <
[email-masked]> wrote:

> Interesting work. I am enjoying the fact that we have two different takes
> on the same problem. The comparisons and discussions will lead us to a
> better overall solution.
>

That was my goal of publishing the draft!

> I’m rather baffled by this definition, and wondering if it’s a mistake or
> if I’m misinterpreting it. Is this an intentional departure from how “RO”
> is typically used within the OAuth 2.0 space? Usually the term RO refers to
> the entity that owns the specific resources the client is requesting
> authorization for. The RO does not typically own the RS itself.
>

Mistake. Thanks for catching!

> To clarify, the User is entering a code in the Client into the GS, or the
User is entering a code into the Client?

If the prior, the QR code also allows a message. I'm envisioning a User
with a mobile phone can scan the QR code which contains a URL at the GS,
and includes the code.

The message would describe what to do and include the code.

>
>    1.
>    2. Clients support multiple interaction modes and may not always know
>    what the GS supports (and vice-versa). For a multi-tenant GS, it may vary
>    by tenant configuration. Clients should be able to say what they can do,
>    and the GS should be able to tell them which one to use. It’s a very simple
>    but powerful inline negotiation.
>
>
That is what is in TxAuth. Would you elaborate on how the GS might be
constrained? Why would the GS not be able to do all?

I would think all constraints would be at the Client. Am I missing
something?

>
>    1.
>    2. I don’t see the value of the “popup” interaction mode. Clients can
>    use “redirect” mode within popups. However, speaking as someone who has
>    done that, I really don’t recommend it. Popups are increasingly
>    unsupported, and prone to weird behavioral issues. In-app browsers in
>    Facebook, Twitter, etc. tend to have popups disabled. The last versions of
>    IE Mobile didn’t support them at all (the popped up page basically just
>    loaded into the current window). in
>
>
Popups are really useful in single-page apps as you want to keep the
context and not reload the page.

Agree that popups don't make sense in mobile. A full redirect does of
course. A single-page app on mobile would open a new tab which would be a
separate context rather than a redirect.

>    1.
> I may want to host my UserInfo endpoint on a separate microservice from my
> token endpoint (in OAuth 2.0/OIDC terms). The former might be part of my
> user profile/directory stack, while the latter is part of the highly
> privileged authentication/authorization stack.
>

The token endpoint has the access token anyway, so it can fetch the data
from the other endpoint itself if it wanted to. IE, there is no separation
of duties.

What are the advantages of the UserInfo endpoint to the User or Client?

The UserInfo endpoint seems to just add more complexity, with no ability to
start a User interaction if additional consent is needed.

> I don’t agree that the use cases are distinct. The only claim that is
> strictly necessary for authentication is the user identifier. Other claims
> like email and phone_number are often used to aid in local account
> identification (i.e., account linking), but are useful and interesting
> beyond this use case.
>

Some Clients use email and phone_number as the identifier and don't pay
attention to the directed identifier. Not the best practice, but it is what
people do.

> Other claims such as name, preferred_username, and birthdate could be used
> in a similar fashion, though they frequently aren’t. The same is true for
> other resources not currently defined as claims (e.g., the externalId
> established when the user was imported through SCIM).
>
>
>
>    - Optionally get the value bundled with the authentication response,
>    without needing to call a separate endpoint.
>
>  In my opinion, all the different ways to get claims in OIDC is a bug, not
a feature. With the optionality at the OP,  a generic Client has to support
both.

>
>    -
>    - Optionally get the value in a signed or encrypted blob.
>
> This optionality is useful to the Client, as it can decide what claims
should be in the signed blob which may be used differently than other
claims.

>    -
>    - Optionally provide some structured metadata describing the resource
>    and/or requested authorization.
>
>

>
>    -
>
>
>
> It’s telling that all of these are optional. If we think these are
> features worth bringing forward into whatever protocol we produce through
> TxAuth, we should look at them independently of the claim/resource
> dichotomy.
>

I agree that these features are orthogonal to the "are claims and resources
the same thing" debate.

I strongly think it is a disservice to our audience to conflate claims and
resources. Claims are statements about the User and read-only.

Resources are independent of the GS. The Client may be able to do all of
CRUD on the resource.

While there is overlap with the UserInfo endpoint that it could be
considered a resource, I don't think that helps the audience.

The language in XAuth can definitely use improvement to provide more
clarity here.

> I understand the use case you’re trying to support here, but I think the
> proposal is too complicated to implement. From the sequences, it looks like
> the Client is expected to issue a Read Grant request, and that connection
> will be kept open while the User is redirected to the GS and goes through
> the authentication workflow (and possibly part of the authorization
> workflow). Only then would the GS return the Read Grant response. Is this
> correct?
>
>
>
> To implement this, the Client has to launch an asynchronous thread to
> execute that request and awaiting the response.
>
Possible, but susceptible to failures. What happens if that thread crashes?
> Or fails to send the Update Grant request to flip interaction.keep to
> false? What is the GS doing in the meantime? Is it just showing the User a
> “loading” widget as it waits for the Client to update the grant? How long
> does it wait for? For mobile apps, that background thread may get killed or
> lose network connectivity as soon as the user gets switched over to the
> system browser to load the GS sign in page. For a pure-JS app that
> redirects, I don’t think this is possible at all. (unless web workers can
> survive page unloads?)
>
>
>
> This is an interesting use case for us to think about, but it needs a lot
> of work and may not be something we should try to bake into the core
> protocol if we don’t need to.
>

It might not have been obvious, but the Client calling the GS to get a
result while the interaction is happening is what happens in any flow with
an interaction started by the Client. It is not unique to
"interaction"."keep" -- we are just adding additional back and forths
between the Client and GS.

A QR Code example HAS to work this way, as there is no other way for the
Client to know the interaction has completed.

Google and Microsoft both have a similar user experience. The User wants to
log into an app -- they are instructed to go to the respective mobile app
to approve the authentication -- and then the User returns to the app which
changes to a logged in state.  An authentication only flow using XAuth
would work the same way.

> I didn’t like this until I realized that you’re distinguishing between
> handles/URIs and tokens. Now that I’ve thought about it more, I like this
> from the standpoint that it underscores the idea of Grants and
> Authorizations being persistent objects within the protocol.
>

:)

> And it’s really just making public something that the GS is probably going
> to be doing under the hood anyway. However, we have to be careful that we
> don’t accidentally encourage implementers to start shoving things into
> these URIs.
>

The URI content is intended to be opaque. There would be security
considerations would keep people from putting visible stuff in there they
shouldn't.

I would expect implementations to use a random value with a checksum, or a
JWT.

> *From: *Txauth <[email-masked]> on behalf of Dick Hardt <
> [email-masked]>
> *Date: *Friday, February 7, 2020 at 8:00 PM
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *[Txauth] XAuth -02
>
>
>
> Authorization has an AuthZ URI..
>
>
>
ᐧ

---

From: Lee McGovern <[email-masked]>
Date: Thu, 13 Feb 2020 08:57:31 +0000

Is an alternative to JOSE being considered for example PASETO?

From: Dick Hardt <[email-masked]>
Sent: Donnerstag, 13. Februar 2020 03:34
To: Richard Backman, Annabelle <[email-masked]>
Cc: [email-masked]
Subject: Re: [Txauth] XAuth -02

On Mon, Feb 10, 2020 at 3:38 PM Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>> wrote:
Interesting work. I am enjoying the fact that we have two different takes on the same problem. The comparisons and discussions will lead us to a better overall solution.

Section 2.1:

Section 5.5.2:

<snip>

3 issues with this:

  1.  How would I do a user code-based interaction?
To clarify, the User is entering a code in the Client into the GS, or the User is entering a code into the Client?

If the prior, the QR code also allows a message. I'm envisioning a User with a mobile phone can scan the QR code which contains a URL at the GS, and includes the code.

  1.

That is what is in TxAuth. Would you elaborate on how the GS might be constrained? Why would the GS not be able to do all?

I would think all constraints would be at the Client. Am I missing something?

  1.
  2.  I don’t see the value of the “popup” interaction mode. Clients can use “redirect” mode within popups. However, speaking as someone who has done that, I really don’t recommend it. Popups are increasingly unsupported, and prone to weird behavioral issues. In-app browsers in Facebook, Twitter, etc. tend to have popups disabled. The last versions of IE Mobile didn’t support them at all (the popped up page basically just loaded into the current window). in

Popups are really useful in single-page apps as you want to keep the context and not reload the page.

Agree that popups don't make sense in mobile. A full redirect does of course. A single-page app on mobile would open a new tab which would be a separate context rather than a redirect.

  1.

Section 12.6:

        endpoint?]

The token endpoint has the access token anyway, so it can fetch the data from the other endpoint itself if it wanted to. IE, there is no separation of duties.

The UserInfo endpoint seems to just add more complexity, with no ability to start a User interaction if additional consent is needed.

Section 12.8:

I don’t agree that the use cases are distinct. The only claim that is strictly necessary for authentication is the user identifier. Other claims like email and phone_number are often used to aid in local account identification (i.e., account linking), but are useful and interesting beyond this use case.

Some Clients use email and phone_number as the identifier and don't pay attention to the directed identifier. Not the best practice, but it is what people do.

Other claims such as name, preferred_username, and birthdate could be used in a similar fashion, though they frequently aren’t. The same is true for other resources not currently defined as claims (e.g., the externalId established when the user was imported through SCIM)..

  *   Optionally get the value bundled with the authentication response, without needing to call a separate endpoint.
 In my opinion, all the different ways to get claims in OIDC is a bug, not a feature. With the optionality at the OP,  a generic Client has to support both.

  *
  *   Optionally get the value in a signed or encrypted blob.
This optionality is useful to the Client, as it can decide what claims should be in the signed blob which may be used differently than other claims.

  *

  *

I agree that these features are orthogonal to the "are claims and resources the same thing" debate.

I strongly think it is a disservice to our audience to conflate claims and resources. Claims are statements about the User and read-only.

Resources are independent of the GS. The Client may be able to do all of CRUD on the resource.

While there is overlap with the UserInfo endpoint that it could be considered a resource, I don't think that helps the audience.

The language in XAuth can definitely use improvement to provide more clarity here.

Section 12.12:

To implement this, the Client has to launch an asynchronous thread to execute that request and awaiting the response.
Possible, but susceptible to failures. What happens if that thread crashes? Or fails to send the Update Grant request to flip interaction.keep to false? What is the GS doing in the meantime? Is it just showing the User a “loading” widget as it waits for the Client to update the grant? How long does it wait for? For mobile apps, that background thread may get killed or lose network connectivity as soon as the user gets switched over to the system browser to load the GS sign in page. For a pure-JS app that redirects, I don’t think this is possible at all. (unless web workers can survive page unloads?)

It might not have been obvious, but the Client calling the GS to get a result while the interaction is happening is what happens in any flow with an interaction started by the Client. It is not unique to "interaction"."keep" -- we are just adding additional back and forths between the Client and GS.

A QR Code example HAS to work this way, as there is no other way for the Client to know the interaction has completed.

Google and Microsoft both have a similar user experience. The User wants to log into an app -- they are instructed to go to the respective mobile app to approve the authentication -- and then the User returns to the app which changes to a logged in state.  An authentication only flow using XAuth would work the same way.

Section 12.14:

        Authorization?*

I didn’t like this until I realized that you’re distinguishing between handles/URIs and tokens. Now that I’ve thought about it more, I like this from the standpoint that it underscores the idea of Grants and Authorizations being persistent objects within the protocol.

:)

And it’s really just making public something that the GS is probably going to be doing under the hood anyway. However, we have to be careful that we don’t accidentally encourage implementers to start shoving things into these URIs.

The URI content is intended to be opaque. There would be security considerations would keep people from putting visible stuff in there they shouldn't.

I would expect implementations to use a random value with a checksum, or a JWT.

–

From: Txauth <[email-masked]<mailto:[email-masked]>> on behalf of Dick Hardt <[email-masked]<mailto:[email-masked]>>
Date: Friday, February 7, 2020 at 8:00 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Txauth] XAuth -02

https://tools.ietf.org/html/draft-hardt-xauth-protocol-02<https://tools..ietf.org/html/draft-hardt-xauth-protocol-02>

/Dick
[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=7cd18ea6-8c50-46dc-be25-e99f614dab82]ᐧ

This e-mail, including attachments, is intended for the person(s) or company named and may contain confidential and/or legally privileged information.

Unauthorized disclosure, copying or use of this information may be unlawful and is prohibited. If you are not the intended recipient, please delete this message and notify the sender.
All incoming and outgoing e-mail messages are stored in the Swiss Re Electronic Message Repository.
If you do not wish the retention of potentially private e-mails by Swiss Re, we strongly advise you not to use the Swiss Re e-mail account for any private, non-business related communications.

---

From: David <[email-masked]>
Date: Thu, 13 Feb 2020 03:51:50 -0700

In what context? I do not believe this draft mandates tokens in a particular format. 

That said - likely not for any standardized communication, since PASETO is a non standardized vendor format. 

-DW

> On Feb 13, 2020, at 1:57 AM, Lee McGovern <[email-masked]> wrote:
> 
> 
> On Mon, Feb 10, 2020 at 3:38 PM Richard Backman, Annabelle <[email-masked]> wrote:
> How would I do a user code-based interaction?
> Clients support multiple interaction modes and may not always know what the GS supports (and vice-versa). For a multi-tenant GS, it may vary by tenant configuration. Clients should be able to say what they can do, and the GS should be able to tell them which one to use. It’s a very simple but powerful inline negotiation.
>  
> I don’t see the value of the “popup” interaction mode. Clients can use “redirect” mode within popups. However, speaking as someone who has done that, I really don’t recommend it. Popups are increasingly unsupported, and prone to weird behavioral issues. In-app browsers in Facebook, Twitter, etc. tend to have popups disabled. The last versions of IE Mobile didn’t support them at all (the popped up page basically just loaded into the current window). in 
>  
> Optionally get the value bundled with the authentication response, without needing to call a separate endpoint.
> Optionally get the value in a signed or encrypted blob.
> Optionally provide some structured metadata describing the resource and/or requested authorization.
>  
>  
>  
>  
> If you do not wish the retention of potentially private e-mails by Swiss Re, we strongly advise you not to use the Swiss Re e-mail account for any private, non-business related communications. -- 
> Txauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth

---

From: Lee McGovern <[email-masked]>
Date: Thu, 13 Feb 2020 11:32:33 +0000

In reference to sections 10.1.3, 10.2.1, 10.2.2, 10.2.3. If the current RFC's for JOSE require the JWT BCP to be implemented correctly perhaps it may be better to start from a new implementation which aims to solve those from the beginning?

From: David <[email-masked]>
Sent: Donnerstag, 13. Februar 2020 11:52
To: Lee McGovern <[email-masked]>
Cc: Dick Hardt <[email-masked]>; Richard Backman, Annabelle <[email-masked]>; [email-masked]
Subject: Re: [Txauth] XAuth -02

-DW

On Feb 13, 2020, at 1:57 AM, Lee McGovern <[email-masked]<mailto:[email-masked]>> wrote:

From: Dick Hardt <[email-masked]<mailto:[email-masked]>>
Sent: Donnerstag, 13. Februar 2020 03:34
To: Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Txauth] XAuth -02

Section 2.1:

Section 5.5.2:

<snip>

3 issues with this:

  1.

  1.

  1.

Section 12.6:

        endpoint?]

Section 12.8:

  *

  *

  *

Section 12.12:

Section 12.14:

        Authorization?*

:)

–

/Dick

[email-masked]<mailto:[email-masked]>

---

From: Dick Hardt <[email-masked]>
Date: Thu, 13 Feb 2020 07:00:18 -0800

I was not familiar PASETO before you mentioned it Lee.

(David: it is an expired RFC,
https://tools.ietf.org/html/draft-paragon-paseto-rfc-00)

An extension could replace the JOSE in section 10 with PASETO.

Any new claim types defined with PASETO could be added to the claims
request (5.5.6) and response (7.4.5)

On Thu, Feb 13, 2020 at 2:51 AM David <[email-masked]> wrote:

> *From:* Dick Hardt <[email-masked]>
> *Sent:* Donnerstag, 13. Februar 2020 03:34
> *To:* Richard Backman, Annabelle <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Txauth] XAuth -02
>
>
>
> The UserInfo endpoint seems to just add more complexity, with no ability
> to start a User interaction if additional consent is needed.
>
>
>
>
>
>
>
> Section 12.8:
>
> established when the user was imported through SCIM)..
>
>
>
> Possible, but susceptible to failures. What happens if that thread
> crashes? Or fails to send the Update Grant request to flip interaction.keep
> to false? What is the GS doing in the meantime? Is it just showing the User
> a “loading” widget as it waits for the Client to update the grant? How long
> Google and Microsoft both have a similar user experience. The User wants
> to log into an app -- they are instructed to go to the respective mobile
> app to approve the authentication -- and then the User returns to the app
> which changes to a logged in state.  An authentication only flow using
> XAuth would work the same way.
>
>
>
>
>
>
>
> Section 12.14:
>
> <https://tools..ietf.org/html/draft-hardt-xauth-protocol-02>
>
>
>
> This e-mail, including attachments, is intended for the person(s) or
> company named and may contain confidential and/or legally privileged
> information.
> Unauthorized disclosure, copying or use of this information may be
> unlawful and is prohibited. If you are not the intended recipient, please
> delete this message and notify the sender.
> If you do not wish the retention of potentially private e-mails by Swiss
> Re, we strongly advise you not to use the Swiss Re e-mail account for any
> private, non-business related communications. --
> Txauth mailing list
> [email-masked]

---

From: Dick Hardt <[email-masked]>
Date: Thu, 13 Feb 2020 07:07:50 -0800

I got distracted and left out responding to one of your comments.

While a single stage Grant request (3.1) in a mobile app that has been put
to sleep will recover fine, a multi-step (3.4) will fail. Since 3.4 only
makes sense if the Client is checking a database along the way, I
would expect the Client to have a server side, and the server could take
each step.

A related point that I did not call out in the draft is that I expect the
connection between the Client and the GS to be maintained between each of
the calls, and by requiring TLS 1.3, there should be no extra round trips
to set up TLS if the connection fails.
ᐧ

On Wed, Feb 12, 2020 at 6:34 PM Dick Hardt <[email-masked]> wrote:

>> I may want to host my UserInfo endpoint on a separate microservice from
>> my token endpoint (in OAuth 2.0/OIDC terms). The former might be part of my
>> Other claims such as name, preferred_username, and birthdate could be
>> used in a similar fashion, though they frequently aren’t. The same is true
>> for other resources not currently defined as claims (e.g., the externalId
>>  In my opinion, all the different ways to get claims in OIDC is a bug,
> not a feature. With the optionality at the OP,  a generic Client has to
> support both.
>
>
>
>>
>>    -
>> And it’s really just making public something that the GS is probably
>> going to be doing under the hood anyway. However, we have to be careful
>> that we don’t accidentally encourage implementers to start shoving things
>> into these URIs.
>>
>
>> Per my last emails, naming is hard, there are likely lots of mistakes,
>> and lots of aspects that need normative language. Hopefully the concepts
>> come through!
>>
>>
>>
>> /Dick
>>
> ᐧ
>

---

From: Brian Campbell <[email-masked]>
Date: Thu, 13 Feb 2020 13:27:14 -0700

FWIW that's not an RFC. It's an expired individual internet draft.

That may seem like a pedantic distinction but this other expired individual
internet draft https://tools.ietf.org/html/draft-abr-twitter-reply-00 is a
nice exemplification of why the distinction is important.

On Thu, Feb 13, 2020 at 8:01 AM Dick Hardt <[email-masked]> wrote:

> https://tools.ietf.org/html/draft-paragon-paseto-rfc-00
> <https://tools..ietf.org/html/draft-paragon-paseto-rfc-00>)
>
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

---

From: Dick Hardt <[email-masked]>
Date: Thu, 13 Feb 2020 12:29:52 -0800

Thanks for clarifying .. they are quite different ... I was careless in my
language.

On Thu, Feb 13, 2020 at 12:27 PM Brian Campbell <[email-masked]>
wrote:

> That may seem like a pedantic distinction but this other expired
> individual internet draft
> https://tools.ietf.org/html/draft-abr-twitter-reply-00 is a nice
> exemplification of why the distinction is important.
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Fri, 14 Feb 2020 02:08:36 +0000

[richanna]
Replies inline
[/richanna]

–

From: Dick Hardt <[email-masked]>
Date: Wednesday, February 12, 2020 at 6:35 PM
To: "Richard Backman, Annabelle" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Txauth] XAuth -02

<snip>

Section 5.5.2:

<snip>

3 issues with this:

[richanna]
By user code-based interaction, I mean the kind described in the OAuth 2.0 Device Authorization Grant<http://tools.ietf.org/html/rfc8628>, where the user receives a code and short URL from the client, navigates to that URL in a browser, and enters the code. While this could be packed into interaction.message, this will lead to clunkier user experiences:

  1.  The GS may not be able to provide localized instructions that match the locale on the Client.
  2.  Suppose the GS sends a message that reads: “Scan the QR code or open a browser to http://code.example/ and enter the code: 12345.”

     *   That instruction does not make sense on a device that does not present a QR code. Imagine hearing that from a smart speaker.
     *   That instruction is confusingly redundant if the Client displays the QR code along with its own instructions, like: “Scan the QR code or follow the instructions below.”

  1.  Will “embed the short URL and code in the message string” be MTI? If not, text-only clients would have a broken experience.
[/richanna]

[richanna]
Clients may support customer-defined GSes (e.g., enterprise IdPs), which will vary in terms of which interaction modes they support. While the set of interactions defined in XAuth might all be MTI for a GS, we should assume that extensions will introduce new interactions which will not be universally supported. An interaction mechanism might have properties that cause some administrators to want to disable it, or to restrict Clients to always use it. Are you assuming that a Client will always make an OPTIONS discovery request first?
[/richanna]

3.   I don’t see the value of the “popup” interaction mode. Clients can use “redirect” mode within popups. However, speaking as someone who has done that, I really don’t recommend it. Popups are increasingly unsupported, and prone to weird behavioral issues. In-app browsers in Facebook, Twitter, etc. tend to have popups disabled. The last versions of IE Mobile didn’t support them at all (the popped up page basically just loaded into the current window). in

[richanna]
Popups are broken and/or disabled in enough instances that we should not encourage their usage by including explicit support for them in the protocol. Nor are they necessary for SPAs in order to restore the state of their app after the redirect. And again, a Client that really wants to give themselves a headache with popups can do that themselves using “redirect” mode. They just have to provide a landing page for the GS to redirect back to that parses the response, passes it back to the main window, and closes itself. I don’t see why the protocol would need to explicitly describe this mechanism.
[/richanna]

Section 12.6:

        endpoint?]

[richanna]
If the access token is sender-constrained, then no, the token endpoint can’t fetch the data itself. But even without the security angle, there is value in separating out the functionality as it allows the GS to distribute it across systems with different owners. E.g., there might be a directory API team that also owns the SCIM interface and UserInfo endpoint.

The advantage for the Client is that they have an endpoint they can call to get up-to-date details about the end user, even outside the context of an active session.

The UserInfo endpoint can indicate the need for additional consent via a 401 and WWW-Authenticate, just like any other resource endpoint.
[/richanna]

Section 12.8:

[richanna]
That is literally the scenario I described in the first part of the second sentence. The latter part of that same sentence notes that those claims are useful beyond that use case, i.e., they can be useful even when the client is not using them for authentication. I am demonstrating that your “authenticating a user vs granting access to a resource” dichotomy is flawed by showing that claims do not strictly belong to the former, and some things that are defined as claims have nothing at all to do with authentication.
[/richanna]

<snip>

[richanna]
Claims are a subset of resources that OIDC built some extra features for, including a read-only interface to access them. However, claims are not inherently read-only, nor are they the only resources for which a read-only interfaces may be built for.
[/richanna]

<snip>

[richanna]
There are two big differences between those examples (e.g., QR Code, app-based login approvals) and this mechanism in XAuth:

  1.  In your examples of this behavior today, the reason for the wait is clear and obvious, and driven by the user. E.g., my printer is waiting for me to go enter this code and log in; Google sign in is waiting for me to tap this button on my phone. That is not the case in the XAuth protocol. The user is left sitting on a loading screen waiting for a behind-the-scenes interaction between client and GS that may not even happen.
  2.  Unlike with code/QR flows or sign-in verification, there is no active process on the client side to keep this async request open. A web app client would have to introduce a server-side async process to manage this aspect of the protocol. That’s not easy.
  3.  The failure modes show up in more appropriate contexts, where there are clear paths forward for the end user. In code/QR-based flows, it’s detected on the client side, in the form of an AS that never provides a response. In that scenario, the client can retry the process. In sign-in verification, the problem occurs between two parts of the AS, and the AS can allow the end user to retry or to use a different authentication method. In the XAuth Create+Update scenario, the failure is detected on the GS, and there is no clear path forward. If the Client never calls Update Grant to flip interaction.keep to false, what should the GS do? How long should it wait? Should it issue the authorization anyway, assuming the Client will come back and ask for it at some point? Should it redirect the end user back to the Client anyway, or drop them on a landing page? Should it flag this as an error, or is this the expected behavior for the Client?

I really think this is overcomplicating the protocol to an extent that no one will actually implement it.
[/richanna]

[pasting in from your later email]
While a single stage Grant request (3.1) in a mobile app that has been put to sleep will recover fine, a multi-step (3.4) will fail. Since 3.4 only makes sense if the Client is checking a database along the way, I would expect the Client to have a server side, and the server could take each step.
[/end paste]

[richanna]
Having a remote database and having a remote server are not the same thing. This adds a lot of complexity to serverless apps.
[/richanna][https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=7cd18ea6-8c50-46dc-be25-e99f614dab82]ᐧ

---

From: Dick Hardt <[email-masked]>
Date: Fri, 14 Feb 2020 09:09:09 -0800

On Thu, Feb 13, 2020 at 6:08 PM Richard Backman, Annabelle <richanna=
[email-masked]> wrote:

> *From: *Dick Hardt <[email-masked]>
> *Date: *Wednesday, February 12, 2020 at 6:35 PM
> *To: *"Richard Backman, Annabelle" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [Txauth] XAuth -02
>
>
>
> <snip>
>
>
>
> Section 5.5.2:
>
> By user code-based interaction, I mean the kind described in the OAuth
> 2.0 Device Authorization Grant <http://tools.ietf.org/html/rfc8628>,
> where the user receives a code and short URL from the client, navigates to
> that URL in a browser, and enters the code. While this could be packed into
> interaction.message, this will lead to clunkier user experiences:
>
>    2. Suppose the GS sends a message that reads: “Scan the QR code or
>    open a browser to http://code.example/ and enter the code: 12345.”
>
>
>    1. That instruction does not make sense on a device that does not
>       present a QR code. Imagine hearing that from a smart speaker.
>       2. That instruction is confusingly redundant if the Client displays
>       the QR code along with its own instructions, like: “Scan the QR code or
>       follow the instructions below.”
>
>
>    1. Will “embed the short URL and code in the message string” be MTI?
>    If not, text-only clients would have a broken experience.
>
> [/richanna]
>

Sounds like a text only interaction type should be added per my note in the
draft. Perhaps even one that is focused on the code flow, where the
parameters are the code and the URI to enter the code, letting the Client
present the parameters with localized content?

> Clients may support customer-defined GSes (e.g., enterprise IdPs), which
> will vary in terms of which interaction modes they support. While the set
> of interactions defined in XAuth might all be MTI for a GS, we should
> assume that extensions will introduce new interactions which will not be
> universally supported. An interaction mechanism might have properties that
> cause some administrators to want to disable it, or to restrict Clients to
> always use it. Are you assuming that a Client will always make an OPTIONS
> discovery request first?
>
> [/richanna]
>

An example of why a given GS may not support a mode would be helpful.

I was envisioning that if an optional to support interaction mode was not
supported at the GS, that it would return an error. The Client would then
try a different one. Alternatively, the Client could start with an OPTIONS
call in cases where the GS is dynamicly chosen.

>
>
> 3.   I don’t see the value of the “popup” interaction mode. Clients can
> Popups are broken and/or disabled in enough instances that we should not
> encourage their usage by including explicit support for them in the
> protocol. Nor are they necessary for SPAs in order to restore the state of
> their app after the redirect.
>

Are they really that broken in desktop? I've used them extensively myself
in the past as it was a better user experience, but that was a few years
ago.

> And again, a Client that really wants to give themselves a headache with
> popups can do that themselves using “redirect” mode. They just have to
> provide a landing page for the GS to redirect back to that parses the
> response, passes it back to the main window, and closes itself. I don’t see
> why the protocol would need to explicitly describe this mechanism.
>
[/richanna]

I think it is a useful signal for the GS in the experience it wants to show
the user.

> If the access token is sender-constrained, then no, the token endpoint
> can’t fetch the data itself. But even without the security angle, there is
> value in separating out the functionality as it allows the GS to distribute
> it across systems with different owners. E.g., there might be a directory
> API team that also owns the SCIM interface and UserInfo endpoint.
>

An implementation can also route calls to different internal systems while
keeping the same endpoint.

I also think of SCiM and UserInfo as very different endpoints. I would
consider SCIM a resource, and UserInfo claims. I appreciate those are
similar in enterprise, but they are not in consumer contexts.

>
>
> The advantage for the Client is that they have an endpoint they can call
> to get up-to-date details about the end user, even outside the context of
> an active session.
>

In enterprise use cases, getting up-to-date information details is fine, as
consent is obtained somewhere else. In the consumer use case, getting new
data about the user without consent is problematic.

>
>
> The UserInfo endpoint can indicate the need for additional consent via a
> 401 and WWW-Authenticate, just like any other resource endpoint.
>

Per above, I don't think of claims as being a resource.

For consumer use cases, the UserInfo adds more moving pieces for the
Client, particularly one that only needs claims. There is an access token,
and an additional endpoint, with potentially different access control.

I think one of our tenets should be to push complexity to the GS vs the
Client.

[/richanna]

> That is literally the scenario I described in the first part of the second
> sentence. The latter part of that same sentence notes that those claims are
> useful *beyond that use case*, i.e., they can be useful even when the
> client is not using them for authentication. I am demonstrating that your
> “authenticating a user vs granting access to a resource” dichotomy is
> flawed by showing that claims do not strictly belong to the former, and
> some things that are defined as claims have nothing at all to do with
> authentication.
>
> [/richanna]
>

Account linking and authentication are not the same. I was clarifying that.
Sorry I was not clear on the purpose of my comment.

Agreed, as noted, my phrasing was not accurate as claims are for more than
authentication.

> Claims are a subset of resources that OIDC built some extra features for,
> including a read-only interface to access them. However, claims are not
> inherently read-only, nor are they the only resources for which a read-only
> interfaces may be built for.
>
> [/richanna]
>

Sure, there are always exceptions, but the UserInfo endpoint is read-only.

If there is a SCIM endpoint, then as stated above, that is a resource.

> There are two big differences between those examples (e.g., QR Code,
> app-based login approvals) and this mechanism in XAuth:
>
>    1. In your examples of this behavior today, the reason for the wait is
>    clear and obvious, and driven by the user. E.g., my printer is waiting for
>    me to go enter this code and log in; Google sign in is waiting for me to
>    tap this button on my phone. That is not the case in the XAuth protocol.
>    The user is left sitting on a loading screen waiting for a
>    behind-the-scenes interaction between client and GS that may not even
>    happen.
>    2. Unlike with code/QR flows or sign-in verification, there is no
>    active process on the client side to keep this async request open. A web
>    app client would have to introduce a server-side async process to manage
>    this aspect of the protocol. That’s not easy.
>    3. The failure modes show up in more appropriate contexts, where there
>    are clear paths forward for the end user. In code/QR-based flows, it’s
>    detected on the client side, in the form of an AS that never provides a
>    response. In that scenario, the client can retry the process. In sign-in
>    verification, the problem occurs between two parts of the AS, and the AS
>    can allow the end user to retry or to use a different authentication
>    method. In the XAuth Create+Update scenario, the failure is detected on the
>    GS, and there is no clear path forward. If the Client never calls Update
>    Grant to flip interaction.keep to false, what should the GS do? How long
>    should it wait? Should it issue the authorization anyway, assuming the
>    Client will come back and ask for it at some point? Should it redirect the
>    end user back to the Client anyway, or drop them on a landing page? Should
>    it flag this as an error, or is this the expected behavior for the Client?
>
>
>

The flow in
https://tools.ietf.org/html/draft-hardt-xauth-protocol-02#section-3.1 is
EXACTLY the same as the Google and Microsoft flows.

While the flow in
https://tools.ietf.org/html/draft-hardt-xauth-protocol-02#section-3.4 has
additional steps, it is not fundamentally any different except the Client
is making another call to the GS after the first one returns. The risk of
the Client not making the second call and leaving the User hanging is not
really any different of the Client not making the first call.

Besides the situation where the mobile device that MAY not be able to make
the second call might put to sleep, I don't see any implementation issues.
TxAuth works the same way as 3.1 as I understand it for non-redirect flows.

> Having a remote database and having a remote server are not the same
> thing. This adds a lot of complexity to serverless apps.
>
> [/richanna]ᐧ
>

Which aspect adds complexity?

The added complexity in keeping an interaction is making an additional API
call after the first API call.

---

From: Justin Richer <[email-masked]>
Date: Fri, 14 Feb 2020 15:17:00 -0500

> I was envisioning that if an optional to support interaction mode was not supported at the GS, that it would return an error. The Client would then try a different one. Alternatively, the Client could start with an OPTIONS call in cases where the GS is dynamicly chosen.
>  

This is pretty simple: I buy my GS from one vendor and download my Client library from another vendor. Both of them support different sets of multiple interaction modes, and they have a non-zero overlap of commonality that neither implementor knows ahead of time. It sounds like your assumption is that clients will be built to talk to a specific GS at all times, that they’re made in pairs tightly coupled to each other. While that was true in the distant past, I don’t think that model holds today. Otherwise they’d always do a discovery step (using OPTIONS here) before talking to the GS. 

In XYZ’s interaction model, the client simply sets up whatever options it can handle, and the AS responds with whatever ones it supports. If that ends up being a zero-set, then the user can’t interact and, most likely, the request fails. This kind of single-step inline negotiation is incredibly powerful.

For the cases where it’s statically known by the developer which modes the server supports, they can send only one. For dynamic cases, you don’t need an extra round trip. And for the complex cases where you could have the user interact in multiple ways (IE, scan a QR code :or: type in a short user code), you don’t have to define a new “type” for each possible combination. 

 — Justin

---

From: Dick Hardt <[email-masked]>
Date: Fri, 14 Feb 2020 13:39:33 -0800

No, I am not expecting Clients to always be built to a specific GS, but
that is the common case today. What has you think that model does not hold
true today?

Your example is a hypothetical that seems very unlikely. Why would a GS
from a vendor not support all defined interaction modes?

The constraints of what is available are at the Client.

We could have XAuth provide a list of types of modes it can support in
preferential order -- but I would prefer to not add complexity unless there
is a clear use case for it.

ᐧ

On Fri, Feb 14, 2020 at 12:17 PM Justin Richer <[email-masked]> wrote:

> This is pretty simple: I buy my GS from one vendor and download my Client
> library from another vendor. Both of them support different sets of
> multiple interaction modes, and they have a non-zero overlap of commonality
> that neither implementor knows ahead of time. It sounds like your
> assumption is that clients will be built to talk to a specific GS at all
> times, that they’re made in pairs tightly coupled to each other. While that
> was true in the distant past, I don’t think that model holds today.
> Otherwise they’d always do a discovery step (using OPTIONS here) before
> talking to the GS.
>
> In XYZ’s interaction model, the client simply sets up whatever options it
> can handle, and the AS responds with whatever ones it supports. If that
> ends up being a zero-set, then the user can’t interact and, most likely,
> the request fails. This kind of single-step inline negotiation is
> incredibly powerful.
>
> For the cases where it’s statically known by the developer which modes the
> server supports, they can send only one. For dynamic cases, you don’t need
> an extra round trip. And for the complex cases where you could have the
> user interact in multiple ways (IE, scan a QR code :or: type in a short
> user code), you don’t have to define a new “type” for each possible
> combination.
>
>  — Justin
>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Sat, 15 Feb 2020 02:29:29 +0000

[richanna]
Replies inline.
[/richanna]

–

From: Txauth <[email-masked]> on behalf of Dick Hardt <[email-masked]>
Date: Friday, February 14, 2020 at 9:10 AM
To: "Richard Backman, Annabelle" <richanna=[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Txauth] XAuth -02

On Thu, Feb 13, 2020 at 6:08 PM Richard Backman, Annabelle <richanna=[email-masked]<mailto:[email-masked]>> wrote:
[richanna]
Replies inline
[/richanna]
<snip>
[richanna]
By user code-based interaction, I mean the kind described in the OAuth 2.0 Device Authorization Grant<http://tools.ietf.org/html/rfc8628>, where the user receives a code and short URL from the client, navigates to that URL in a browser, and enters the code. While this could be packed into interaction.message, this will lead to clunkier user experiences:

a.    That instruction does not make sense on a device that does not present a QR code. Imagine hearing that from a smart speaker.

b.   That instruction is confusingly redundant if the Client displays the QR code along with its own instructions, like: “Scan the QR code or follow the instructions below.”

3.   Will “embed the short URL and code in the message string” be MTI? If not, text-only clients would have a broken experience.
[/richanna]

Sounds like a text only interaction type should be added per my note in the draft. Perhaps even one that is focused on the code flow, where the parameters are the code and the URI to enter the code, letting the Client present the parameters with localized content?

[richanna]
I think we’re approaching the “interaction” concept wrong. We’re conflating three different things together:

  *   What does the Client need to send the end user to the GS?

     *   A human-friendly short URL and code.
     *   Any kind of URL, as long and ugly as it needs to be.

  *   How will the Client receive the response from the GS?

     *   Client will make a request to the GS.
     *   GS will make a request to the Client. (I’ve had to implement this for a custom integration, including it to demonstrate that other options exist)

  *   Will the GS return the end user to the Client, and if so how?

     *   Yes, by URL redirect.
     *   No.

Here is a very non-normative example request fragment, for a client that wants both a short URL plus code and a full URL so they can opportunistically use one or the other (AWS CLI v2 does this), will query the GS for the response, and wants the GS to redirect to a publicly accessible URL on the Client’s website after the flow (e.g., to show further documentation/branded content to the end user):
{
"interact": {
  "code": { "max": 8 },
  "url": true
},
"response": {
  "poll": true
},
"return": {
  "url": "https://help.smartdevice.example/post-setup"
}
}

And here is an equally non-normative example response fragment:
{
"interact": {
  "code": "123456",
  "code_url": "https://gs.example/code",
  "url": "https://gs.example/xauth/12343567890abcdef1234567890abcdef"
}
}

(Seriously do not read too much into these parameter names or syntax, this is just to give a rough sense of how I’m thinking about this. Anyone who tries to pick apart this example will be responded to with mocking memes.)
[/richanna]

[richanna]

[richanna]
Lots of ASes don’t support Device Authorization Grant. I think it’s safe to assume that interaction mode support will vary for XAuth as well. “Keep trying until you find one that works” sounds pretty painful for the client, and doesn’t allow the client to use multiple interaction modes, as demonstrated in my example above.

There are lots of reasons for wanting to support multiple modes:

  *   Some people are comfortable with QR codes, some aren’t.
  *   Some people have smart phones that can scan them, some don’t.
  *   People with smart phones may want to go through the authentication flow on their desktop instead.
  *   Some people may have to go through the authentication flow on their desktop, because the GS thinks iPhones only support Bluetooth-based security keys and insists they cannot complete the login flow even though they have two YubiKey 5Ci keys on their account. (HI, GOOGLE ACCOUNT PROTECTION PROGRAM)
[/richanna]

3.   I don’t see the value of the “popup” interaction mode. Clients can use “redirect” mode within popups. However, speaking as someone who has done that, I really don’t recommend it. Popups are increasingly unsupported, and prone to weird behavioral issues. In-app browsers in Facebook, Twitter, etc. tend to have popups disabled. The last versions of IE Mobile didn’t support them at all (the popped up page basically just loaded into the current window).. in

[richanna]
Popups are broken and/or disabled in enough instances that we should not encourage their usage by including explicit support for them in the protocol. Nor are they necessary for SPAs in order to restore the state of their app after the redirect.

Are they really that broken in desktop? I've used them extensively myself in the past as it was a better user experience, but that was a few years ago.

[richanna]
Popup blockers are built in and aggressively enabled by default on all major browsers. Communicating securely between windows is not easy, and from past experience prone to failure thanks to weird browser bugs. Trusted Site settings in IE and Edge can blow the whole thing up in weird ways (speaking again from experience).

Also, it’s 2020. Stop branching on mobile vs. desktop. I get that lots of people still do that, but that doesn’t mean the protocol should cater to it.
[/richanna]
And again, a Client that really wants to give themselves a headache with popups can do that themselves using “redirect” mode. They just have to provide a landing page for the GS to redirect back to that parses the response, passes it back to the main window, and closes itself. I don’t see why the protocol would need to explicitly describe this mechanism.
[/richanna]

I think it is a useful signal for the GS in the experience it wants to show the user.

[richanna]
Useful how? The window dimensions are a better signal for how to present the user experience. (*cough* responsive design *cough*)
[/richanna]

Section 12.6:

        endpoint?]

[richanna]

An implementation can also route calls to different internal systems while keeping the same endpoint.

I also think of SCiM and UserInfo as very different endpoints. I would consider SCIM a resource, and UserInfo claims. I appreciate those are similar in enterprise, but they are not in consumer contexts.

[richanna]
Routing calls to different internal systems still means I have to have some shared infrastructure that both teams manage. It’s more complex than it needs to be.

I’m going to suggest we move this part of the discussion to a separate thread because it’s too messy to keep in this awful back-and-forth. I’ll just add here that I’m not suggesting we only have a UserInfo endpoint. I’m arguing two things:

  1.  The UserInfo endpoint is good, actually. It doesn’t need to be MTI, but we should not preclude its existence.
  2.  If we provide a mechanism for requesting and receiving claims in the GS Read Grant response, that mechanism should apply generically to arbitrary resources. GSes can support it or not, for any given resource.
[/richanna]

<snip>
[richanna]

The flow in https://tools.ietf.org/html/draft-hardt-xauth-protocol-02#section-3.1 is EXACTLY the same as the Google and Microsoft flows.

While the flow in https://tools.ietf.org/html/draft-hardt-xauth-protocol-02#section-3.4 has additional steps, it is not fundamentally any different except the Client is making another call to the GS after the first one returns. The risk of the Client not making the second call and leaving the User hanging is not really any different of the Client not making the first call.

Besides the situation where the mobile device that MAY not be able to make the second call might put to sleep, I don't see any implementation issues. TxAuth works the same way as 3.1 as I understand it for non-redirect flows.

[richanna]
I don’t think you actually read what I wrote. If the flows are exactly the same, tell me:

  1.  What does the user think is going on while they’re sitting on the GS, watching a spinner as the GS waits for the Client to make an Update Grant request in 3.4?
  2.  What existing Client component is holding open the Read Grant request?

     *   If your answer is “an async process on the Client’s server” then please re-read the second word of that question.

  1.  How long should the GS wait for the Client to make the Update Grant request in 3.4? What should the GS do if that never happens? What is the path forward for the end user, at that point?
[/richanna]

[richanna]

The added complexity in keeping an interaction is making an additional API call after the first API call.

[richanna]
The issue isn’t the API call itself, it’s the need for the Client to maintain a persistent, asynchronous process to make that API call.

It is incorrect to assume that every app with a database will necessarily have a server side. A serverless app that does a redirect to the GS, or that switches to an external browser (and thus may be put to sleep) has no component that will reliably stay alive to hold open the Read Grant request, receive the response, and follow up with an Update Grant request (i.e., flow 3.4). Adding a server-side component to do this orchestration adds significant complexity.
[/richanna]

---

From: Justin Richer <[email-masked]>
Date: Sat, 15 Feb 2020 17:50:34 -0500

The interaction model that Annabelle describes below is exactly the kind of thing that’s in XYZ:

https://oauth.xyz/interaction/

An earlier implementation of XYZ had a “type” field like XAuth does. You can see that here:

https://tools.ietf.org/html/draft-richer-transactional-authz-00#section-2.4

We moved away from it for all of the reasons Annabelle is citing, along with the others I’ve stated previously on the list that I don’t feel bear repeating again. Having implemented both patterns directly in the same project, I can attest that the code paths are significantly simpler  for the current XYZ pattern, especially on the Authorization Server. You can look at our code yourselves, if you like.

And for the “simple” client case that supports only one type (which I think we all believe will be the overwhelmingly common case), I want to point out that the XYZ approach and the XAuth approach are for all intents and purposes identical. The XYZ approach allows for a lot more flexibility along with a decrease in complexity. 

 — Justin

> On Feb 14, 2020, at 9:29 PM, Richard Backman, Annabelle <richanna=[email-masked]> wrote:
> 
> [richanna]
> Replies inline.
> [/richanna]
>  
> –
> https://aws.amazon.com/identity/ <https://aws.amazon.com/identity/>
>  
>  
> From: Txauth <[email-masked] <mailto:[email-masked]>> on behalf of Dick Hardt <[email-masked] <mailto:[email-masked]>>
> To: "Richard Backman, Annabelle" <richanna=[email-masked] <mailto:richanna=[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> On Thu, Feb 13, 2020 at 6:08 PM Richard Backman, Annabelle <richanna=[email-masked] <mailto:[email-masked]>> wrote:
>> [richanna]
>> Replies inline
>> [/richanna] 
>> <snip>
>> [richanna]
>> By user code-based interaction, I mean the kind described in the OAuth 2.0 Device Authorization Grant <http://tools.ietf.org/html/rfc8628>, where the user receives a code and short URL from the client, navigates to that URL in a browser, and enters the code. While this could be packed into interaction.message, this will lead to clunkier user experiences:
>> 2.   Suppose the GS sends a message that reads: “Scan the QR code or open a browser to http://code.example/ <http://code.example/> and enter the code: 12345.”
>> 
> What does the Client need to send the end user to the GS?
> A human-friendly short URL and code.
> Any kind of URL, as long and ugly as it needs to be.
> How will the Client receive the response from the GS?
> Client will make a request to the GS.
> GS will make a request to the Client. (I’ve had to implement this for a custom integration, including it to demonstrate that other options exist)
> Will the GS return the end user to the Client, and if so how?
> Yes, by URL redirect.
> No.
>  
>   "url": "https://help.smartdevice.example/post-setup <https://help.smartdevice.example/post-setup>"
> }
> }
>  
>   "code_url": "https://gs.example/code <https://gs.example/code>",
>   "url": "https://gs.example/xauth/12343567890abcdef1234567890abcdef <https://gs.example/xauth/12343567890abcdef1234567890abcdef>"
> }
> }
>  
> Some people are comfortable with QR codes, some aren’t.
> Some people have smart phones that can scan them, some don’t.
> People with smart phones may want to go through the authentication flow on their desktop instead.
> Some people may have to go through the authentication flow on their desktop, because the GS thinks iPhones only support Bluetooth-based security keys and insists they cannot complete the login flow even though they have two YubiKey 5Ci keys on their account. (HI, GOOGLE ACCOUNT PROTECTION PROGRAM)
> [/richanna]
>>  
> The UserInfo endpoint is good, actually. It doesn’t need to be MTI, but we should not preclude its existence.
> If we provide a mechanism for requesting and receiving claims in the GS Read Grant response, that mechanism should apply generically to arbitrary resources. GSes can support it or not, for any given resource.
> [/richanna]
>  
> <snip>
>> [richanna]
> The flow in https://tools.ietf.org/html/draft-hardt-xauth-protocol-02#section-3.1 <https://tools.ietf.org/html/draft-hardt-xauth-protocol-02#section-3.1> is EXACTLY the same as the Google and Microsoft flows. 
>  
> While the flow in https://tools.ietf.org/html/draft-hardt-xauth-protocol-02#section-3.4 <https://tools.ietf.org/html/draft-hardt-xauth-protocol-02#section-3.4> has additional steps, it is not fundamentally any different except the Client is making another call to the GS after the first one returns. The risk of the Client not making the second call and leaving the User hanging is not really any different of the Client not making the first call.
>  
> What does the user think is going on while they’re sitting on the GS, watching a spinner as the GS waits for the Client to make an Update Grant request in 3.4?
> What existing Client component is holding open the Read Grant request?
> If your answer is “an async process on the Client’s server” then please re-read the second word of that question.
> How long should the GS wait for the Client to make the Update Grant request in 3.4? What should the GS do if that never happens? What is the path forward for the end user, at that point?
> [/richanna]
>>  
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>-- 
> Txauth mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Mon, 17 Feb 2020 18:54:24 +0000

XYZ is a lot closer to what I’m describing, but it still conflates “redirect to this URL after the workflow” with “send the response to this URL”. I *think* the draft as written would allow a Client to provide a callback but also poll for the response, but it’s not very clear. This kind of flow where the Client is actually split between device, backend, and webapp within a single transaction is one that deserves more attention, IMHO.

This note on https://oauth.xyz/interaction/ also suggests XYZ is more limited than it needs to be, but the draft seems to allow for this already so maybe this note is just be out of date?

It would be interesting to figure out if we can combine both the user code and arbitrary redirect URL methods, giving the user a few options. This should be as simple as allowing more flexibility on the interaction request portion and having the server return all possible options.

–

From: Justin Richer <[email-masked]>
Date: Saturday, February 15, 2020 at 2:51 PM
To: "Richard Backman, Annabelle" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [UNVERIFIED SENDER] Re: [Txauth] XAuth -02

 — Justin

On Feb 14, 2020, at 9:29 PM, Richard Backman, Annabelle <richanna=[email-masked]<mailto:richanna=[email-masked]>> wrote:

[richanna]
Replies inline.
[/richanna]

–

From: Txauth <[email-masked]<mailto:[email-masked]>> on behalf of Dick Hardt <[email-masked]<mailto:[email-masked]>>
Date: Friday, February 14, 2020 at 9:10 AM
To: "Richard Backman, Annabelle" <richanna=[email-masked]<mailto:richanna=[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Txauth] XAuth -02

[richanna]

·         What does the Client need to send the end user to the GS?

o    A human-friendly short URL and code.

o    Any kind of URL, as long and ugly as it needs to be.

·         How will the Client receive the response from the GS?

o    Client will make a request to the GS.

o    GS will make a request to the Client. (I’ve had to implement this for a custom integration, including it to demonstrate that other options exist)

·         Will the GS return the end user to the Client, and if so how?

o    Yes, by URL redirect.

o    No.

[richanna]

[richanna]

·         Some people are comfortable with QR codes, some aren’t.

·         Some people have smart phones that can scan them, some don’t.

·         People with smart phones may want to go through the authentication flow on their desktop instead.

·         Some people may have to go through the authentication flow on their desktop, because the GS thinks iPhones only support Bluetooth-based security keys and insists they cannot complete the login flow even though they have two YubiKey 5Ci keys on their account. (HI, GOOGLE ACCOUNT PROTECTION PROGRAM)
[/richanna]

[richanna]

[richanna]

[richanna]

Section 12.6:

        endpoint?]

[richanna]

[richanna]

<snip>
[richanna]

[richanna]

a.       If your answer is “an async process on the Client’s server” then please re-read the second word of that question.

3.       How long should the GS wait for the Client to make the Update Grant request in 3.4? What should the GS do if that never happens? What is the path forward for the end user, at that point?
[/richanna]

[richanna]

[richanna]

---

From: Justin Richer <[email-masked]>
Date: Mon, 17 Feb 2020 15:28:24 -0500

Ah yes, looks like the website is out of date — that note dates to a previous iteration where we had an explicit “type” field and we were already seeing the limitations of that style. You’re right that the spec, the actual text on the website’s examples, and our implementation all allow combining these two. In fact, there’s an example of it on that page! You can absolutely poll and wait for a callback, both use a transaction continuation request. I’ll clean that up, thanks! 

And in the XYZ model, “send the response to this URL” would be a different interaction type to be requested from the client if it’s got a different set of considerations than the callback URL. However, I’m curious what “the response” would be in that case. Are we talking a front-channel response, still, like the implicit flow? Or are we looking for a way to push information back to the client in the back channel? If it’s the latter, then that’s definitely a different interaction style. And one of the good things in XYZ is that getting info back to the client is now decoupled from how you get the user involved, so the user could enter a code or go to a long (or short) arbitrary URL, and the client’s means of getting to the next step are the same menu of options regardless. 

 — Justin

> On Feb 17, 2020, at 1:54 PM, Richard Backman, Annabelle <[email-masked]> wrote:
> 
> This note on https://oauth.xyz/interaction/ <https://oauth.xyz/interaction/> also suggests XYZ is more limited than it needs to be, but the draft seems to allow for this already so maybe this note is just be out of date?
>  
> From: Justin Richer <[email-masked] <mailto:[email-masked]>>
> To: "Richard Backman, Annabelle" <[email-masked] <mailto:[email-masked]>>
> https://oauth.xyz/interaction/ <https://oauth.xyz/interaction/>
>  
> https://tools.ietf.org/html/draft-richer-transactional-authz-00#section-2.4 <https://tools.ietf.org/html/draft-richer-transactional-authz-00#section-2.4>
>  
>> On Feb 14, 2020, at 9:29 PM, Richard Backman, Annabelle <richanna=[email-masked] <mailto:richanna=[email-masked]>> wrote:
>>  
>> [richanna]
>> Replies inline.
>> [/richanna]
>>  
>> –

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Mon, 17 Feb 2020 22:10:05 +0000

XYZ seems to assume that a callback URL can be used to continue the transaction at the RC (i.e., it’s like the redirect_uri in the OAuth 2.0 authorization code grant). Consider my example in reply to Dick, where a smart device will poll for the response, but wants to direct the end user to an introduction/tutorial page hosted on the manufacturer’s website. The website has no knowledge of the XYZ transaction. I *think* XYZ supports this, but it’s not obvious and I can imagine that AS support or prohibition would more often stem from side effects of how the AS was written rather than as an explicit feature decision.

But it’s also worth considering cases where the transaction might be continued through the callback URL, but the response is still destined for the device. For example, suppose a Client uses the callback URL to present the end user with an opportunity to link to an existing account at the RC. If the end user has multiple accounts at the AS, then at this point they might realize they signed into the wrong one, and want to switch. Ideally the end user would not have to manually reboot the whole process from the smart device, since they’re already sitting at a browser. Or consider the case where an end user authorizes some but not all of the access requested by the Client. The callback URL could land them on a page that explains the benefit they would get from granting the rejected access. Ideally the end user would be able to modify the grant through that browser session. A similar interaction might happen far out of band from the original authorization, for example if the end user chooses from within a management app for their smart device to enable a feature that requires additional authorization.

–

From: Txauth <[email-masked]> on behalf of Justin Richer <[email-masked]>
Date: Monday, February 17, 2020 at 12:29 PM
To: "Richard Backman, Annabelle" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Txauth] [UNVERIFIED SENDER] Re: XAuth -02

 — Justin

On Feb 17, 2020, at 1:54 PM, Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>> wrote:

–

From: Justin Richer <[email-masked]<mailto:[email-masked]>>
Date: Saturday, February 15, 2020 at 2:51 PM
To: "Richard Backman, Annabelle" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [UNVERIFIED SENDER] Re: [Txauth] XAuth -02

 — Justin

[richanna]
Replies inline.
[/richanna]

–

[richanna]

•         What does the Client need to send the end user to the GS?

•         How will the Client receive the response from the GS?

•         Will the GS return the end user to the Client, and if so how?

o    Yes, by URL redirect.

o    No.

[richanna]

[richanna]

•         Some people are comfortable with QR codes, some aren’t.

•         Some people have smart phones that can scan them, some don’t.

•         People with smart phones may want to go through the authentication flow on their desktop instead.

•         Some people may have to go through the authentication flow on their desktop, because the GS thinks iPhones only support Bluetooth-based security keys and insists they cannot complete the login flow even though they have two YubiKey 5Ci keys on their account. (HI, GOOGLE ACCOUNT PROTECTION PROGRAM)
[/richanna]

[richanna]

[richanna]

[richanna]

Section 12.6:

        endpoint?]

[richanna]

[richanna]

<snip>
[richanna]

[richanna]

[richanna]

[richanna]

---

From: Justin Richer <[email-masked]>
Date: Mon, 17 Feb 2020 18:03:01 -0500

Thanks for the explanation, that’s helpful. XYZ’s “callback” structure is indeed for continuing the transaction, like the redirect URI but with the features of PKCE and State built-in and required. For the kind of more static post-authorization redirect you’re asking for, I wouldn’t call that a callback and would expect it to have another URLs in the request. The same mechanism could be used for the client pushing a URL to have backchannel messages pushed directly to it. All of these should be allowable in parallel and separate from how the user gets out to the server.

 — Justin

> On Feb 17, 2020, at 5:10 PM, Richard Backman, Annabelle <[email-masked]> wrote:
> 
>> On Feb 17, 2020, at 1:54 PM, Richard Backman, Annabelle <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Dick Hardt <[email-masked]>
Date: Mon, 17 Feb 2020 16:21:39 -0800

On Fri, Feb 14, 2020 at 6:29 PM Richard Backman, Annabelle <richanna=
[email-masked]> wrote:

> [richanna]
>
> Replies inline.
>
> [/richanna]
>
>  Sounds like a text only interaction type should be added per my note in
> the draft. Perhaps even one that is focused on the code flow, where the
> I think we’re approaching the “interaction” concept wrong. We’re
> conflating three different things together:
>
>    - What does the Client need to send the end user to the GS?
>
>
>    - A human-friendly short URL and code.
>       - Any kind of URL, as long and ugly as it needs to be.
>
>
>    - How will the Client receive the response from the GS?
>
>
>    - Client will make a request to the GS.
>       - GS will make a request to the Client. (I’ve had to implement this
>       for a custom integration, including it to demonstrate that other options
>       exist)
>
>
>    - Will the GS return the end user to the Client, and if so how?
>
>
>    - Yes, by URL redirect.
>       - No.
>
> Your suggestions are capabilities oriented, similar (as noted in later
emails) as in XYZ.

XAuth is centered around the user experience the Client is able to deliver.

There is always some artifact the Client is getting the User to provide the
GS.

> Lots of ASes don’t support Device Authorization Grant. I think it’s safe
> to assume that interaction mode support will vary for XAuth as well. “Keep
> trying until you find one that works” sounds pretty painful for the client,
> and doesn’t allow the client to use multiple interaction modes, as
> demonstrated in my example above.
>

If the device can only show a text string, that is all it can do. The
Client can't move forward with either XYZ or XAuth if the AS/GS does not
support a user code.

>    - Some people are comfortable with QR codes, some aren’t.
>    - Some people have smart phones that can scan them, some don’t.
>    - People with smart phones may want to go through the authentication
>    flow on their desktop instead.
>    - Some people may *have* to go through the authentication flow on
>    their desktop, because the GS thinks iPhones only support Bluetooth-based
>    security keys and insists they cannot complete the login flow even though
>    they have two YubiKey 5Ci keys on their account. (HI, GOOGLE ACCOUNT
>    PROTECTION PROGRAM)
>
> All of your examples are choices for the User, which the Client would need
to present to the User.

Per my comment above based on your suggestion, "qrcode" also shows the
"code" information, which satisfies all your suggestions above.

> Popup blockers are built in and aggressively enabled by default on all
> major browsers. Communicating securely between windows is not easy, and
> from past experience prone to failure thanks to weird browser bugs. Trusted
> Site settings in IE and Edge can blow the whole thing up in weird ways
> (speaking again from experience).
>

I checked what popular sites listed at
https://ahrefs.com/blog/most-visited-websites/ use:

- sites that use popups

- pinterest
- expedia
- tripadvisor
- nytimes
- indeed.com
- quora
- redfin
- trulia

- sites that use a full page redirect

- IMDB - an Amazon property =)

Looks like most sites prefer popups and have figured out how to do it --
except IMDB.

>
>
> Also, it’s 2020. Stop branching on mobile vs. desktop. I get that lots of
> people still do that, but that doesn’t mean the protocol should cater to it.
>

Mobile and desktop are different though. They don't offer the same
experiences.

On mobile, a GS may have a mobile app that can receive push notifications.
The security parameters are different.

Some implementations will want to know which platform is being used. We
should not remove that signal for them.

> Useful how? The window dimensions are a better signal for how to present
> the user experience. (*cough* responsive design *cough*)
>
> [/richanna]
>

Responsive design is one way to address things. Lots of apps still have an
m.example.com site for mobile content.

Our goal is not to decide how an app should build a user experience. We
should give them as much useful signal as they may need to make their own
choices.

> Routing calls to different internal systems still means I have to have
> some shared infrastructure that both teams manage. It’s more complex than
> it needs to be.
>

For the GS. It is simpler for the Client. As stated, I think we should push
complexity to the GS all other things being equal.

>
>
> I’m going to suggest we move this part of the discussion to a separate
> thread because it’s too messy to keep in this awful back-and-forth. I’ll
> just add here that I’m not suggesting we *only* have a UserInfo endpoint.
> I’m arguing two things:
>
>    1. The UserInfo endpoint is good, actually. It doesn’t need to be MTI,
>    but we should not preclude its existence.
>    2. If we provide a mechanism for requesting and receiving claims in
>    the GS Read Grant response, that mechanism should apply generically to
>    arbitrary resources. GSes can support it or not, for any given resource.
>
>
agree on moving this to another thread.

I disagree completely on your statements. We are designing a protocol,
where interop and security should be chosen over having numerous ways to do
accomplish the same thing.

> I don’t think you actually read what I wrote. If the flows are exactly the

I did. I'm not sure we are talking about the same Google and Microsoft
flows because your questions are making untrue statements.
he
eg: in (2), there is an active process in the Client waiting for the server
to respond when the user has completed the authentication. As soon as
authentication completes in the mobile phone, the Client change to an
authenticated state.

>    1. What does the user think is going on while they’re sitting on the
>    GS, watching a spinner as the GS waits for the Client to make an Update
>    Grant request in 3.4?
>
> I said the flows are exactly the same for 3.1

>    1. If your answer is “an async process on the Client’s server” then
>       please re-read the second word of that question.
>
> As I stated, the only *potential* issue is with multi-step flows on mobile
where the app is shut down.

>
>    1.
>
>
>    1. How long should the GS wait for the Client to make the Update Grant
>    request in 3.4? What should the GS do if that never happens? What is the
>    path forward for the end user, at that point?
>
>
3.1 has the GS waiting for the Client as well. All the same questions apply
to any aspect of the protocol where one party does not do the next step.
The User is the most likely party to not continue. What do the GS and
Client do if the User has been sent to the GS, but walks away from their
device?

> The issue isn’t the API call itself, it’s the need for the Client to
> maintain a persistent, asynchronous process to make that API call.
>

The 3.1 flow, and all the XYZ flows where there is no redirect all have the
same requirement of the Client.

An async call to a server is pretty straight forward in all modern web
languages.

If the Client is a mobile app put to sleep, it can remake the call to the
GS and get the results in a 3.1 flow.

>
>
> It is incorrect to assume that every app with a database will necessarily
> have a server side. A serverless app that does a redirect to the GS, or
> that switches to an external browser (and thus may be put to sleep) has no
> component that will reliably stay alive to hold open the Read Grant
> request, receive the response, and follow up with an Update Grant request
> (i.e., flow 3.4). Adding a server-side component to do this orchestration
> adds significant complexity.
>

3.4 is not a required flow for the Client, and is an edge case for
sophisticated Clients.

ᐧ

---

From: Dick Hardt <[email-masked]>
Date: Mon, 17 Feb 2020 16:31:48 -0800

I did not see the suggestion for the device to ask the GS to send the User
to a new page on completion. Great idea. Will add it to the next draft.

wrt. your example of a user that did not authorize all the requests. The
Client won't know that until the User has completed the request, so the
Client can't determine which page to send the User to until then.

with the Client and GS having a dialog at the same time as the User and GS
interact, the Client can provide the GS with a page appropriate for the
user responses. The flow in 3.4 in XAuth.

ᐧ

On Mon, Feb 17, 2020 at 2:10 PM Richard Backman, Annabelle <richanna=
[email-masked]> wrote:

> XYZ seems to assume that a callback URL can be used to continue the
> transaction at the RC (i.e., it’s like the redirect_uri in the OAuth 2.0
> authorization code grant). Consider my example in reply to Dick, where a
> smart device will poll for the response, but wants to direct the end user
> to an introduction/tutorial page hosted on the manufacturer’s website. The
> website has no knowledge of the XYZ transaction. I **think** XYZ supports
> this, but it’s not obvious and I can imagine that AS support or prohibition
> would more often stem from side effects of how the AS was written rather
> than as an explicit feature decision.
>
>
>
> But it’s also worth considering cases where the transaction might be
> continued through the callback URL, but the response is still destined for
> the device. For example, suppose a Client uses the callback URL to present
> the end user with an opportunity to link to an existing account at the RC.
> If the end user has multiple accounts at the AS, then at this point they
> might realize they signed into the wrong one, and want to switch. Ideally
> the end user would not have to manually reboot the whole process from the
> smart device, since they’re already sitting at a browser. Or consider the
> case where an end user authorizes some but not all of the access requested
> by the Client. The callback URL could land them on a page that explains the
> benefit they would get from granting the rejected access. Ideally the end
> user would be able to modify the grant through that browser session. A
> similar interaction might happen far out of band from the original
> authorization, for example if the end user chooses from within a management
> app for their smart device to enable a feature that requires additional
> authorization.
>
>
>
> –
>
> *From: *Txauth <[email-masked]> on behalf of Justin Richer <
> [email-masked]>
> *Date: *Monday, February 17, 2020 at 12:29 PM
> *Subject: *Re: [Txauth] [UNVERIFIED SENDER] Re: XAuth -02
>
>
>
> Ah yes, looks like the website is out of date — that note dates to a
> previous iteration where we had an explicit “type” field and we were
> already seeing the limitations of that style. You’re right that the spec,
> the actual text on the website’s examples, and our implementation all allow
> combining these two. In fact, there’s an example of it on that page! You
> can absolutely poll and wait for a callback, both use a transaction
> continuation request. I’ll clean that up, thanks!
>
>
>
> And in the XYZ model, “send the response to this URL” would be a different
> interaction type to be requested from the client if it’s got a different
> set of considerations than the callback URL. However, I’m curious what “the
> response” would be in that case. Are we talking a front-channel response,
> still, like the implicit flow? Or are we looking for a way to push
> information back to the client in the back channel? If it’s the latter,
> then that’s definitely a different interaction style. And one of the good
> things in XYZ is that getting info back to the client is now decoupled from
> how you get the user involved, so the user could enter a code or go to a
> long (or short) arbitrary URL, and the client’s means of getting to the
> next step are the same menu of options regardless.
>
>
>
>  — Justin
>
>
>
> XYZ is a lot closer to what I’m describing, but it still conflates
> “redirect to this URL after the workflow” with “send the response to this
> URL”. I **think** the draft as written would allow a Client to provide a
> callback but also poll for the response, but it’s not very clear. This kind
> of flow where the Client is actually split between device, backend, and
> webapp within a single transaction is one that deserves more attention,
> IMHO.
>
>
>
> This note on https://oauth.xyz/interaction/ also suggests XYZ is more
> limited than it needs to be, but the draft seems to allow for this already
> so maybe this note is just be out of date?
>
>
>
> It would be interesting to figure out if we can combine both the user code
> and arbitrary redirect URL methods, giving the user a few options. This
> should be as simple as allowing more flexibility on the interaction request
> portion and having the server return all possible options.
>
>
>
> –
>
> *From: *Justin Richer <[email-masked]>
> *Date: *Saturday, February 15, 2020 at 2:51 PM
> *Subject: *[UNVERIFIED SENDER] Re: [Txauth] XAuth -02
>
>
>
> We moved away from it for all of the reasons Annabelle is citing, along
> with the others I’ve stated previously on the list that I don’t feel bear
> repeating again. Having implemented both patterns directly in the same
> project, I can attest that the code paths are significantly simpler  for
> the current XYZ pattern, especially on the Authorization Server. You can
> look at our code yourselves, if you like.
>
>
>
> And for the “simple” client case that supports only one type (which I
> think we all believe will be the overwhelmingly common case), I want to
> point out that the XYZ approach and the XAuth approach are for all intents
> and purposes identical. The XYZ approach allows for a lot more flexibility
> along with a decrease in complexity.
>
>
>
>  — Justin
>
>
>
>
>
>
> On Feb 14, 2020, at 9:29 PM, Richard Backman, Annabelle <
> richanna=[email-masked]> wrote:
>
>
>
> [richanna]
>
> Replies inline.
>
> [/richanna]
>
>
>
> –
>
> *Date: *Friday, February 14, 2020 at 9:10 AM
> *To: *"Richard Backman, Annabelle" <richanna=[email-masked]>
> 2.   Suppose the GS sends a message that reads: “Scan the QR code or open
> a browser to http://code.example/ and enter the code: 12345.”
>
> a.    That instruction does not make sense on a device that does not
> b.   That instruction is confusingly redundant if the Client displays the
> QR code along with its own instructions, like: “Scan the QR code or follow
> the instructions below.”
>
> 3.   Will “embed the short URL and code in the message string” be MTI? If
> not, text-only clients would have a broken experience.
>
> [/richanna]
>
>
>
> o    GS will make a request to the Client. (I’ve had to implement this
> Here is a very non-normative example request fragment, for a client that
> wants both a short URL plus code and a full URL so they can
> opportunistically use one or the other (AWS CLI v2 does this), will query
> the GS for the response, and wants the GS to redirect to a publicly
> accessible URL on the Client’s website after the flow (e.g., to show
> further documentation/branded content to the end user):
>
> {
>
> "interact": {
>
>   "code": { "max": 8 },
>
>   "url": true
>
> },
>
> "response": {
>
>   "poll": true
>
> },
>
> "return": {
>
> (Seriously do not read too much into these parameter names or syntax, this
> is just to give a rough sense of how I’m thinking about this. Anyone who
> tries to pick apart this example will be responded to with mocking memes.)
>
> [/richanna]
>
>
>
>
>
> ·         People with smart phones may want to go through the
> authentication flow on their desktop instead.
>
> ·         Some people may *have* to go through the authentication flow on
> loaded into the current window).. in
>
>
>
> 1.       The UserInfo endpoint is good, actually. It doesn’t need to be
> MTI, but we should not preclude its existence.
>
> 1.       What does the user think is going on while they’re sitting on
> the GS, watching a spinner as the GS waits for the Client to make an Update
> Grant request in 3.4?
>
> a.       If your answer is “an async process on the Client’s server” then
> 3.       How long should the GS wait for the Client to make the Update
> Grant request in 3.4? What should the GS do if that never happens? What is
> the path forward for the end user, at that point?
>
> [/richanna]
>
>
>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Tue, 18 Feb 2020 02:26:00 +0000

–

Date: Monday, February 17, 2020 at 4:22 PM

On Fri, Feb 14, 2020 at 6:29 PM Richard Backman, Annabelle <richanna=[email-masked]<mailto:[email-masked]>> wrote:

<snip>

·      Some people may have to go through the authentication flow on their desktop, because the GS thinks iPhones only support Bluetooth-based security keys and insists they cannot complete the login flow even though they have two YubiKey 5Ci keys on their account. (HI, GOOGLE ACCOUNT PROTECTION PROGRAM)
All of your examples are choices for the User, which the Client would need to present to the User.

Per my comment above based on your suggestion, "qrcode" also shows the "code" information, which satisfies all your suggestions above.

[richanna]
Yes, I am justifying the value of allowing Clients to request and present multiple interaction methods by providing these are some examples of cases where it provides clear benefit to the end user. You can see this implemented in the AWS CLI v2’s support for AWS SSO. And “Scan this <QR code> or <alternate instructions>” is a pretty common pattern for anything involving QR codes. Where did you suggest that the “qrcode” interaction object would include the code information? Are you referring to your comment proposing a “text only interaction type”? That comment sounded like an either/or to me, as in the Client could opt for the text-only interaction that provides them the code or the qrcode interaction that provides them a short URL, not both.
[/richanna]

<snip>

I checked what popular sites listed at https://ahrefs.com/blog/most-visited-websites/ use:

- sites that use popups
- pinterest
- expedia
- tripadvisor
- nytimes
- indeed.com<http://indeed.com>
- quora
- redfin
- trulia

Looks like most sites prefer popups and have figured out how to do it -- except IMDB.

[richanna]
I just tried using Google Sign In on Pinterest, Expedia, and IMDb, when accessed via a link in a Facebook post in the Facebook app. Guess which one worked and which two didn’t? 😃 This perfectly illustrates my point that popups are unreliable, and can fail in weird ways.
[/richanna]

Also, it’s 2020. Stop branching on mobile vs.. desktop. I get that lots of people still do that, but that doesn’t mean the protocol should cater to it.

Mobile and desktop are different though. They don't offer the same experiences.

On mobile, a GS may have a mobile app that can receive push notifications. The security parameters are different.

Some implementations will want to know which platform is being used. We should not remove that signal for them.

[richanna]
My comment was aimed at the implication that Clients might opt to use a popup interaction mode on “desktop” but do something different (e.g., redirect) on mobile. In any case, if the Client is implementing redirect for mobile anyway, then it is not much work for them to wrap that in a popup if they really want that experience on desktop.
[/richanna]

[richanna]

Responsive design is one way to address things. Lots of apps still have an m.example.com<http://m.example.com> site for mobile content.

Our goal is not to decide how an app should build a user experience. We should give them as much useful signal as they may need to make their own choices.

[richanna]
What signal though? What useful information does the GS get out of knowing that the Client intends to open the interaction URI in a popup, that it doesn’t already have more accurate sources for? I mentioned responsive design because the only thing I can think of is that it might inform how the GS presents the sign in experience, but “popup” on its own doesn’t necessarily mean it will be a small or portrait-dimensioned window. So the GS is still just guessing until it’s actually loaded in the popup, and at that point it can check the actual window dimensions and use CSS media queries, etc.
[/richanna]

<snip>

3.1 has the GS waiting for the Client as well. All the same questions apply to any aspect of the protocol where one party does not do the next step. The User is the most likely party to not continue. What do the GS and Client do if the User has been sent to the GS, but walks away from their device?

[richanna]
In step 3.4, steps 6 through 8, the GS returns the Read Grant response (6), the Client evaluates it (7), and then the Client makes an Update Grant request to the GS (8). Throughout this time, the end user is sitting at the GS…watching a spinner, I guess? How long does the AS wait for the Update Grant request? What if it never comes? I’m not talking about the end user walking away, I’m talking about the Client failing to tell the GS to advance the flow.
[/richanna]

<snip>

The 3.1 flow, and all the XYZ flows where there is no redirect all have the same requirement of the Client.

An async call to a server is pretty straight forward in all modern web languages.

If the Client is a mobile app put to sleep, it can remake the call to the GS and get the results in a 3.1 flow.

[richanna]
It’s not just an async call to a server, it’s an async call initiated while handling an HTTP request and that survives the completion of that request. This is not trivial, and even where there are tools to help with this they are often full of sharp edges and introduce fun new failure modes (Does your implementation fail fast when your async thread pool gets exhausted? No? Better hope your users like 503s…).

I suggest a separate thread for this one as well.
[/richanna]
[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=b64950d4-d58f-4bf6-9752-543b82133f34]ᐧ

---

From: Matthew De Haast <[email-masked]>
Date: Tue, 18 Feb 2020 13:16:44 +0200

Thanks for this Dick. Appreciate the draft to be able to compare ideas to
XYZ. The rational section also helped as it answered some of the questions
I was going to ask.

1. OPTIONS for metadata. I really like this way of asking for metadata on
the resources.

2. We have both the Read Grant endpoint and then an explicit Token Refresh
endpoint? Is it not possible that if a client wanted to refresh the tokens
it could just do a Read against the grant? Thinking aloud, the biggest
issue with what I propose is token lifecycle and how to handle that.

3. 5.5.4 Authorization Object.

one of the following values: "oauth_scope" or
      "oauth_rich"

Is there a specific reason to try support both methods? I would prefer this
to be collapsed to a singular new definition for authorization, similar to
RAR, to reduce confusion.

4. 4. Grant and Authz Lifecycle

> At any point in time, there can only be one Grant for the GS, Client,
>    and User tuple.
>
> The Grant/Authz lifecycle isn't clear for our use-case. How would the
current API handle a client getting one time authz to perform singular
financial transactions? There could be multiple of these auths for a single
client at the same time.

5. I am also in agreement with Annabelle that it seems better for the
Client to inform the GS on what interactions are possible and let the GS
decide.

Matt

On Tue, Feb 18, 2020 at 4:26 AM Richard Backman, Annabelle <richanna=
[email-masked]> wrote:

> *Date: *Monday, February 17, 2020 at 4:22 PM
> Yes, I am justifying the value of allowing Clients to request and present
> multiple interaction methods by providing these are some examples of cases
> where it provides clear benefit to the end user. You can see this
> implemented in the AWS CLI v2’s support for AWS SSO. And “Scan this <QR
> code> or <alternate instructions>” is a pretty common pattern for anything
> involving QR codes. Where did you suggest that the “qrcode” interaction
> object would include the code information? Are you referring to your
> comment proposing a “text only interaction type”? That comment sounded like
> an either/or to me, as in the Client could opt for the text-only
> interaction that provides them the code or the qrcode interaction that
> provides them a short URL, not both.
>
> [/richanna]
>
>
>
> <snip>
>
>
>
> I just tried using Google Sign In on Pinterest, Expedia, and IMDb, when
> accessed via a link in a Facebook post in the Facebook app. Guess which one
> worked and which two didn’t? 😃 This perfectly illustrates my point that
> popups are unreliable, and can fail in weird ways.
>
> [/richanna]
>
>
>
>
>
> Also, it’s 2020. Stop branching on mobile vs.. desktop. I get that lots of
> My comment was aimed at the implication that Clients might opt to use a
> popup interaction mode on “desktop” but do something different (e.g.,
> redirect) on mobile. In any case, if the Client is implementing redirect
> for mobile anyway, then it is not much work for them to wrap that in a
> popup if they really want that experience on desktop.
>
> [/richanna]
>
>
>
> What signal though? What useful information does the GS get out of knowing
> that the Client intends to open the interaction URI in a popup, that it
> doesn’t already have more accurate sources for? I mentioned responsive
> design because the only thing I can think of is that it might inform how
> the GS presents the sign in experience, but “popup” on its own doesn’t
> necessarily mean it will be a small or portrait-dimensioned window. So the
> GS is still just guessing until it’s actually loaded in the popup, and at
> that point it can check the actual window dimensions and use CSS media
> queries, etc.
>
> [/richanna]
>
>
>
> <snip>
>
>
>
> 3.   How long should the GS wait for the Client to make the Update Grant
> 3.1 has the GS waiting for the Client as well. All the same questions
> apply to any aspect of the protocol where one party does not do the next
> step. The User is the most likely party to not continue. What do the GS and
> In step 3.4, steps 6 through 8, the GS returns the Read Grant response
> (6), the Client evaluates it (7), and then the Client makes an Update Grant
> request to the GS (8). Throughout this time, the end user is sitting at the
> GS…watching a spinner, I guess? How long does the AS wait for the Update
> Grant request? What if it never comes? I’m not talking about the end user
> walking away, I’m talking about the Client failing to tell the GS to
> advance the flow.
>
> [/richanna]
>
>
>
> <snip>
>
>
>
> It’s not just an async call to a server, it’s an async call initiated
> while handling an HTTP request and that survives the completion of that
> request. This is not trivial, and even where there are tools to help with
> this they are often full of sharp edges and introduce fun new failure modes
> (Does your implementation fail fast when your async thread pool gets
> exhausted? No? Better hope your users like 503s…).
>
>
>

---

From: Dick Hardt <[email-masked]>
Date: Tue, 18 Feb 2020 11:02:57 -0800

> provides them a short URL, not both.

Yes, I thought I had included a link to the section in the latest I have
yet to publish.

https://dickhardt.github.io/hardt-xauth-protocol/draft-hardt-xauth-protocol.html#name-interaction-types

"qrcode"- A QR Code and a user code with URL to navigate to

"code"- A user code with URL to navigate to

> popups are unreliable, and can fail in weird ways.

Your scenario is a little terse for me to follow, but it does not really
matter. Most large site are happy with doing a popup. Who are we to tell
them not too?

Your criticism is that it might not always work. It would be different is
there was a security vulnerability, but that is not what I am understanding
from your criticism.

> that point it can check the actual window dimensions and use CSS media

In XAuth I am proposing that the GS closes the popup window. One less thing
for a Client to do, and and negates any communication issue between the
popup and the main window.

A Client using a popup may be a useful signal for the GS in doing threat
and risk analysis.

> walking away, I’m talking about the Client failing to tell the GS to

1) 3.4 is for a sophisticated Client that wants to incrementally ask for
authorization from the GS, and a GS that supports it.

2) There are lots of web apps that call a backend service and are waiting
for something to complete. So yes, the GS would let the User know it is
waiting.

3) How long to wait? Whatever the GS thinks is reasonable, and not any
different than other experiences where the app is waiting for a backend
process.

4) The same situation can happen in 3.1. Steps (4) and (5) can happen
independent of each other. Step (5) could happen sometime after Step (7),
in which case the User is waiting for the Client to call.

My point about the User walking away is that there are numerous ways for
the protocol to not complete.

> I suggest a separate thread for this one as well.

I don't understand why you think an async pool is needed. A dumb Client can
syncronously make a call, wait for a response, and then make the next call.

The code in a GS is more complicated, as it needs to coordinate calls from
the Client with interactions with the User, but that is the case in 3.1 as
well.

ᐧ

---

From: Dick Hardt <[email-masked]>
Date: Tue, 18 Feb 2020 11:14:03 -0800

> issue with what I propose is token lifecycle and how to handle that.

I was thinking a read against the Grant would return everything in the
Grant, which would include a refresh of all tokens, and return all claims

There is the edge case where an Authorization had been deleted directly,
and then what does a read of the Grant do. Does it create a new
Authorization?

A number of questions to explore here. We are still bouncing around ideas!

> Is there a specific reason to try support both methods? I would prefer
> this to be collapsed to a singular new definition for authorization,
> similar to RAR, to reduce confusion.
>

My understanding of RAR was that it was scopes + authorization details. Is
that not the case?

The reason to have oauth_scope was to have a clear path for existing
implementations to migrate to XAuth. A GS may ONLY support oauth_scope.

> financial transactions? There could be multiple of these auths for a single

If the Client knows all the AuthZs it needs, it can request them all in one
Grant.

If not, the Client can request multiple Grants, that each returns an
Authorization. The Authorization lives on until it is used.

Assuming a refresh or update of the Authorization is not needed, there is
no need to return an AuthZ URI in the Grant.

Is there a requirement to have each Grant continue on?

> Client to inform the GS on what interactions are possible and let the GS

Would you elaborate on why? I understand the flexibility of the Client and
GS being able to negotiate, but I have yet to hear a use case where that is
needed.

>> Also, it’s 2020. Stop branching on mobile vs.. desktop. I get that lots
>> of people still do that, but that doesn’t mean the protocol should cater to
>> it.
>>
>>
>>
>> On mobile, a GS may have a mobile app that can receive push
>> notifications. The security parameters are different.
>>
>>
>>
>> Responsive design is one way to address things. Lots of apps still have
>> an m.example.com site for mobile content.
>>
>>
>>
>> What signal though? What useful information does the GS get out of
>> knowing that the Client intends to open the interaction URI in a popup,
>> that it doesn’t already have more accurate sources for? I mentioned
>> responsive design because the only thing I can think of is that it might
>> inform how the GS presents the sign in experience, but “popup” on its own
>> doesn’t necessarily mean it will be a small or portrait-dimensioned window.
>> So the GS is still just guessing until it’s actually loaded in the popup,
>> and at that point it can check the actual window dimensions and use CSS
>> media queries, etc.
>>
>> [/richanna]
>>
>>
>>
>> <snip>
>>
>>
>>
>> maintain a persistent, asynchronous process to make that API call..
>>
>>
>>
ᐧ

---

From: Matthew De Haast <[email-masked]>
Date: Fri, 21 Feb 2020 16:16:40 +0200

On Tue, Feb 18, 2020 at 9:14 PM Dick Hardt <[email-masked]> wrote:

>> 2. We have both the Read Grant endpoint and then an explicit Token
>> Refresh endpoint? Is it not possible that if a client wanted to refresh the
>> tokens it could just do a Read against the grant? Thinking aloud, the
>> biggest issue with what I propose is token lifecycle and how to handle that.
>>
>

It would be a far nicer API having it a single endpoint IMO. Maybe fleshing
out the AuthZ and Grant relation more with some consideration to enabling
this use case can be done. From the current wording it would appear if an
auth was deleted the grant would return no authorization object. Not sure
if that is intended.

> My understanding of RAR was that it was scopes + authorization details. Is

That is the case, my wording was left open ended in case we felt its
datamodel didn't fully suite TxAuth.

> implementations to migrate to XAuth. A GS may ONLY support oauth_scope.
There is a balance that is going to have to be played between simplifying
the spec and providing for the easier migration. My opinion would be to
optimize for simplicity. The reason I feel that should be the priority is
that we are defining a completely new spec. Lets try keep it clean whilst
we have the ability too. What we can try our best doing is make the spec
easy to write libraries that make migration easy. For example, writing a
library that converts current oauth scopes to OauthX equivalents and back
to make it easier for applications wishing to migrate.

> If the Client knows all the AuthZs it needs, it can request them all in
> one Grant.
>

Clients won't know all AuthZ's ahead of time. They will be requested as
needed. Authorizations would need the ability to refresh the AuthZ.

Which loops back to the above conversation regarding refreshing Authz by
reading a grant. If only a singular grant was allowed, this wouldn't be
possible if it was coupled to the Authz. I would like us to explore this
more and see how to make this possible.

> GS being able to negotiate, but I have yet to hear a use case where that is
Will follow up this later. Just catching up on some more the discussion in
the new thread.

Matt

---

From: Justin Richer <[email-masked]>
Date: Fri, 21 Feb 2020 11:18:33 -0500

> On Feb 21, 2020, at 9:16 AM, Matthew De Haast <matt=[email-masked]> wrote:
> 
> 
> On Tue, Feb 18, 2020 at 9:14 PM Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> On Tue, Feb 18, 2020 at 3:17 AM Matthew De Haast <matt=[email-masked] <mailto:[email-masked]>> wrote:
> Thanks for this Dick. Appreciate the draft to be able to compare ideas to XYZ. The rational section also helped as it answered some of the questions I was going to ask.
> 
> 1. OPTIONS for metadata. I really like this way of asking for metadata on the resources.
> 
> 2. We have both the Read Grant endpoint and then an explicit Token Refresh endpoint? Is it not possible that if a client wanted to refresh the tokens it could just do a Read against the grant? Thinking aloud, the biggest issue with what I propose is token lifecycle and how to handle that.
> 
> I was thinking a read against the Grant would return everything in the Grant, which would include a refresh of all tokens, and return all claims
> 

This isn’t particularly idiomatic for HTTP, where a GET request isn’t supposed to create something new. 

> There is the edge case where an Authorization had been deleted directly, and then what does a read of the Grant do. Does it create a new Authorization?
> 
> It would be a far nicer API having it a single endpoint IMO. Maybe fleshing out the AuthZ and Grant relation more with some consideration to enabling this use case can be done. From the current wording it would appear if an auth was deleted the grant would return no authorization object. Not sure if that is intended.

+1

> Is there a specific reason to try support both methods? I would prefer this to be collapsed to a singular new definition for authorization, similar to RAR, to reduce confusion.
> 
> My understanding of RAR was that it was scopes + authorization details. Is that not the case?
> 
> That is the case, my wording was left open ended in case we felt its datamodel didn't fully suite TxAuth.
>  
> The reason to have oauth_scope was to have a clear path for existing implementations to migrate to XAuth. A GS may ONLY support oauth_scope. 
> 
> 
> There is a balance that is going to have to be played between simplifying the spec and providing for the easier migration. My opinion would be to optimize for simplicity. The reason I feel that should be the priority is that we are defining a completely new spec. Lets try keep it clean whilst we have the ability too. What we can try our best doing is make the spec easy to write libraries that make migration easy. For example, writing a library that converts current oauth scopes to OauthX equivalents and back to make it easier for applications wishing to migrate.

Huge +1. This is our opportunity to make something new without dragging unnecessary baggage. We can learn from the past without repeating it. Take the best parts, the parts that will make our lives easier for the next decade — not the things that’ll make a migration in 3 months from now slightly easier. This is why I favor mapping concepts instead of reusing mechanisms. 

> The Grant/Authz lifecycle isn't clear for our use-case. How would the current API handle a client getting one time authz to perform singular financial transactions? There could be multiple of these auths for a single client at the same time.
> 
> If the Client knows all the AuthZs it needs, it can request them all in one Grant.
> 
> If not, the Client can request multiple Grants, that each returns an Authorization. The Authorization lives on until it is used. 
> 
> Assuming a refresh or update of the Authorization is not needed, there is no need to return an AuthZ URI in the Grant.
> 
> Clients won't know all AuthZ's ahead of time. They will be requested as needed. Authorizations would need the ability to refresh the AuthZ.
> 
> Which loops back to the above conversation regarding refreshing Authz by reading a grant. If only a singular grant was allowed, this wouldn't be possible if it was coupled to the Authz. I would like us to explore this more and see how to make this possible.
> 
>  
> 
> 5. I am also in agreement with Annabelle that it seems better for the Client to inform the GS on what interactions are possible and let the GS decide.
> 
> Would you elaborate on why? I understand the flexibility of the Client and GS being able to negotiate, but I have yet to hear a use case where that is needed.
> 
> 
> Will follow up this later. Just catching up on some more the discussion in the new thread.
> 
> Matt
> ᐧ
> -- 
> Txauth mailing list

---

From: Dick Hardt <[email-masked]>
Date: Fri, 21 Feb 2020 11:14:31 -0800

On Fri, Feb 21, 2020 at 6:17 AM Matthew De Haast <[email-masked]> wrote:

>>> Thanks for this Dick. Appreciate the draft to be able to compare ideas
>>> to XYZ. The rational section also helped as it answered some of the
>>> questions I was going to ask.
>>>
> It would be a far nicer API having it a single endpoint IMO.
>

Why is that? In XAuth, each grant is a new URI.

> Maybe fleshing out the AuthZ and Grant relation more with some
> consideration to enabling this use case can be done.
>

Are you referring to the refresh use case?

An option would be that the Grant only contains the AuthZ URI. The Client
needs to call the AuthZ URI to get an access token. Then all access token
management is done at the AuthZ URI. If the access token can not be
refreshed, then it is included in the Grant. Do you have other suggestions?

> From the current wording it would appear if an auth was deleted the grant
> would return no authorization object. Not sure if that is intended.
>

If we want to acquire more than one authorization at a time, and manage
them independently, then we need different URIs.

> to make it easier for applications wishing to migrate.

Libraries are not going to help an AS migrate. All their documentation and
machinery is set up for scopes.

While we are on the topic of scopes, there are new use cases where the
existing scopes are not expressive enough, but there are fine for many use
cases.

Why not let everyone keep using what works and not have to learn a new way
to represent resources? If it is not broken for them, why fix it?

> more and see how to make this possible.

The GS can decide if an Authorization can be refreshed. It can also decide
to not return an AuthZ URI with the access token.

Does the suggestion above work?

Return an access token in the Grant if it can not be managed.

Return only an AuthZ URi if the Grant can be managed.

The contents of a Grant are then static.

>> Would you elaborate on why? I understand the flexibility of the Client
>> and GS being able to negotiate, but I have yet to hear a use case where
>> that is needed.
>>
>>

---

From: Dick Hardt <[email-masked]>
Date: Fri, 21 Feb 2020 11:16:18 -0800

> supposed to create something new.

I did not consider this a new thing, but the latest version of it.

ᐧ