Re: [Txauth] XAuth -02

[Dick Hardt <[e-mail]>]

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 <[e-mail]> wrote:

> 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 <[e-mail]>
> wrote:
>
> 
>
> Is an alternative to JOSE being considered for example PASETO?
>
>
>
>
>
> *From:* Dick Hardt <[e-mail]>
> *Sent:* Donnerstag, 13. Februar 2020 03:34
> *To:* Richard Backman, Annabelle <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* Re: [Txauth] XAuth -02
>
>
>
> 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 <
> [e-mail]> 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!
>
>
>
>
>
> 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.
>
>
>
> Mistake. Thanks for catching!
>
>
>
>
>
> 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?
>
> 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.
>
>
>
> 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.
>
>
>
>
>
> 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.
>
>
>
>
>
>
>
> 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.
>
>
>
> 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)..
>
>
>
> 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.
>
>  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.
>
>
>
>
>
>
>
> 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.
>
>
>
> 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:
>
>         *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.
>
>
>
> 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.
>
>
>
>
>
> –
>
> Annabelle Backman (she/her)
>
> AWS Identity
>
> https://aws.amazon.com/identity/
>
>
>
>
>
> *From: *Txauth <[e-mail]> on behalf of Dick Hardt <
> [e-mail]>
> *Date: *Friday, February 7, 2020 at 8:00 PM
> *To: *"[e-mail]" <[e-mail]>
> *Subject: *[Txauth] XAuth -02
>
>
>
> I've heavily revised XAuth again.
>
>
>
> https://tools.ietf.org/html/draft-hardt-xauth-protocol-02
> <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
>
> ᐧ
>
> 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. --
> Txauth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>
>