Re: [Txauth] XYZ-08 vs XAuth-08

comments inline ...

On Sun, Jun 7, 2020 at 1:41 PM Justin Richer <jricher@mit.edu> wrote:

> Hi Dick, responses inline.
>
> On Jun 7, 2020, at 3:27 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
>
> Hello
>
> I have just posed some updates on the XAuth draft:
>
> In -07 I added the XYZ features of interaction negotiation, and a Client
> Handle for dynamic clients. I also updated the name to GNAP, but preserved
> the draft-hardt-xauth-protocol filename for ease of tracking changes.
>
> In -08 I split the doc into: core protocol, advanced features, and JOSE
> authentication.
>
> https://www.ietf.org/id/draft-hardt-xauth-protocol-08.html
> https://www.ietf.org/id/draft-hardt-gnap-advanced-00.html
> https://www.ietf.org/id/draft-hardt-gnap-jose-00.html
>
> IMHO, the main doc is much more readable. :)
>
>
> I think that renaming your individual draft is premature and presumptive,
> as the WG has not yet decided on an approach for the WG base draft and
> renaming one of the input drafts like this is going to simply add to
> confusion when trying to discuss and compare different approaches. I would
> recommend undoing this name change in order to facilitate discussion going
> forward, to allow people to refer to one project with a single name and
> know what it means.
>
> As you and I have discussed offline, and as you yourself suggested, it
> might be beneficial for the working group to start from a new draft
> document incorporating the most important features. Until we reach that
> point, renaming any of the input drafts into what the group’s target draft
> will be is going to cause problems.
>

My intent was to remove confusion, not create confusion. Per my comments
below, I refer to my draft as XAuth, and your draft as XYZ. The filename
still has -xauth- and not -gnap-.

I have pushed a -09 that has additional text in the introduction to clarify
it should be referred to as XAuth.

https://www.ietf.org/id/draft-hardt-xauth-protocol-09.html

I named the other files with draft-hardt-gnap to make it clear the document
is related to the proposed GNAP WG.

>
>
> *XYZ vs XAuth*
>
> The remaining major differences between XYZ and XAuth are areas I have
> concerns about. (I will continue to use XYZ and XAuth refer to each draft).
> The concerns are:
>
> *1) API in JSON vs URI and HTTP Verb*
>
> In XYZ, all calls are to the same endpoint as an HTTP POST. The AS must
> parse the JSON to determine what to do.
>
> XAuth has a RESTful interface. A Grant Request starts at the GS URI, and
> Grants and Authorizations are returned as URI resources. Creating a Grant
> is done with a POST, reading a Grant is done with a GET.
>
> With URIs and HTTP verbs, A large scale GS can easily implement
> independent services for each  functionality as routing of requests can be
> done at the HTTP layer based on the URI and HTTP verb. This allows a
> separation of concerns, independent deployment, and resiliency.
>
>
> As I have said many, many times, both on the list and in the documentation
> for XYZ, this is an area that is worth discussing within the working group.
> It’s been tagged a potential direction in XYZ from early days, but not
> something that we’ve pursued because it hasn’t been needed in the spaces
> we’ve used it.
>
> So saying this is a fundamental aspect of XYZ and implying that it’s a
> non-starter for it to not be built that way is misdirection. I hope that
> the conversation here in this group can continue without you ignoring or
> dismissing previous statements like this as we discuss things.
>

I'm comparing the two drafts we have today, not what the drafts could be.
You have consistently stated that there is just one end point in the XYZ
model, and that handles represent the transaction rather than URIs -- as you
state again below in your response to point 4.

I find it is much easier for people to understand a proposal to write it
up. I could not see how to easily modify XYZ to support the models I
envisioned, which is why I wrote XAuth.

>
> Additionally, I find XAuth’s restrictions on the structure of the Grant
> URI potentially problematic, namely that it has to start with the server’s
> URL. This will lead to deployments needing to bend their setups with
> proxies or redirectors to make things fit, which you yourself have said is
> going to be an issue for things like supporting a short redirect URL vs. a
> long redirect URL. Your complaint there was one of latency and complexity,
> why does that not apply here? But most fundamentally, I do not see what
> value this restriction brings to the system. If the value is coming back
> from the GS endpoint, and the client is getting all of its pointers from
> there, what’s the point of dictating how that has to look?
>

Requiring the Grant URI to start with the GS URI is open to discussion. It
is not clear to me why a deployment would need to have a redirector. Large
scale deployments I have worked on have a router / proxy that routes
requests to internal services. Having all the URIs start with the GS URI
enables all GNAP operations to be routed in the same place.

An advantage of starting with the GS URI is that any software on the Client
side knows which GS it belongs to. A Grant URI passed to a Client in a GS
initiated login allows the Client to know if it trusts the GS before
operating on the Grant URI.

If the Grant URI can be any URI, then a Client could be tricked into
operating on a Grant URI it should not be operating on.

>
>
> *2) Handles for all Clients vs Client ID and Client Handle*
>
> In XYZ, both pre-registered clients and dynamic clients use a handle.
>
> In XAuth, the Client ID refers to a pre-registered client, and the Client
> Handle is specific to an instance of a dynamic client. Using separate terms
> clearly differentiates which identifier is being presented to the GS.
>
> This allows a GS to use separate mechanisms for managing pre-registered
> clients and dynamic clients, an important consideration as there can easily
> be millions of instances of a single dynamic client.
>
> Additionally, developers are already familiar with what a Client ID is for
> pre-registered clients.
>
>
> I see the inconsistency in the XAuth draft to be problematic. Under this
> proposed model, I now need to be able to track clients using different
> kinds of identifiers depending on what kind of registration they used? Why
> build in this dichotomy?
>

A GS implementation is free to use the same identifiers and storage system
for Client IDs and Client Handles.

>
> One of the design goals of XYZ was to bring consistency to the haphazard
> world of OAuth 2, where a client ID could mean a class of client software
> or an individual client or a cluster of servers or any number of other
> things.
>

In XYZ a client handle refers to both registered clients, and dynamic
clients. That seems to continue to be haphazard.

Dynamic Registration needed to use Client ID as the rest of OAuth only
understood that identifier for a client.

XAuth allows each type of client to have their own identifier.

>
> And as I’ve demonstrated with an implementation on top of the MITREid
> Connect OAuth 2 server, it’s completely possible and well within-protocol
> to pass in a static client ID within the XYZ’s “key handle” field and have
> things work as expected. Yes, it’s called something different — but if
> that’s a problem, then XAuth’s renaming of the Authorization Server to a
> Grant Server is going to be significantly more confusing for developers,
> don’t you think?
>

Nope.

>
>
> *3) Transaction Handles are One Time Use*
>
> In XYZ, transaction handles are one time use [1]. In the OAuth WG
> discussion on one time use refresh tokens, clients are often distributed
> across components, which complicates one time use references.
>
> One time use transaction handles also makes them inconsistent with the
> display, resource, user, and key handles.
>
>
> Transaction handles being one-time-use is based on experience with a
> session fixation attack against UMA (now patched):
>
>
> https://kantarainitiative.org/confluence/display/uma/Understanding+the+Session+Fixation+Attack+on+UMA+Claims-Gathering+and+the+Provided+Mitigation
>
> Clients with distributed components are going to have to be considered in
> our core model, and so there are considerations and tradeoffs in terms of
> security and deployability that we need to address here. These are the same
> kinds of discussions that we’re having in OAuth 2, as you point out, and so
> we can not only apply that experience and knowledge to this, but we can
> build something that behaves better than a refresh token for this purpose.
>

The XAuth proposal is to use a URI to represent the authorization.

>
>
> *4) New User Identifier*
>
> XYZ introduces a new identifier for the user, a User Handle. Unclear why
> a new type of user identifier is needed, except for the desire to have a
> handle for everything.
>
>
> This is based directly on the Persisted Claims Token concept from UMA2,
> where a client (that is trusted to make such a statement) can say that it
> reasonably believes that the current user interacting with this client is
> the same user that it’s been interacting with before, for use with a future
> request. An AS can take this signal into consideration when processing the
> request, potentially avoiding unnecessary interaction and friction.
>

My statement is that it was unclear why it was needed. Perhaps you can add
a Rationale section to XYZ?

>
> I’m not surprised that you see this as “just applying a handle for
> everything” considering you’ve previously objected to the use of the
> pass-by-reference construct for other aspects of the protocol in the past
> as well. Each component in XYZ that has a separate handle has one for
> specific and documented reasons, and it’s a core feature that these are
> handled (pun intended) in a consistent and predictable manner.
>

This is why I state that it seems hard to change (1) above.

>
> *5) Interaction Capabilities vs Modes*
>
> In XYZ, the capabilities are expressed by the client, and the GS states
> which capabilities it will accept. This can make it difficult for the GS to
> enforce the interaction choices as the client can mix and match which
> capabilities are returned. For example, a GS may not want to support a
> redirect without a callback to protect itself from session fixation
> attacks. In XAuth, the interaction modes provide clarity on the mode of
> interaction and the security properties. For example the GS may support
> both user_code and redirect modes, but not the indirect mode which is
> subject to session fixation attacks.
>
>
> If the GS doesn’t want to accept a redirect without a callback, it can
> because the request will have a redirect, but not a callback, and it can
> reject the request. What makes you believe that this is not detectable or
> not possible in XYZ?
>

I did not say it could not be done, I'm saying it is more difficult in XYZ
than in XAuth

>
> The modes in XAuth are much more limiting, as the mixing of different
> interaction methods is already something that we need to start figuring
> out. Let’s say, for example, a client can do a redirect, accept a
> CIBA-style ping, or do a direct app2app communication. There’s a natural
> preference the client will have here: if it can talk to another app
> directly, it’ll try that first. If that doesn’t work, it can get a push
> notification sent, and if all that fails, it can pop open a browser. If I
> have to pick just one of those modes when I make the request, then the
> client needs to make three different requests to the AS before I get
> anything that works.
>

Have you read the revised draft? As I noted above, I have added
negotiation. The Client can state all the modes it wants, the GS can
respond with the modes it will support, and the Client can offer the User
any modes returned from the GS.

>
> This kind of mixing is important to allow for different modalities of
> client. In fact, the return callback could be tied to the entry of a user
> code, not just an outbound redirect. How the client gets the user to the AS
> and how the user gets back are separate questions, and we need flexibility
> in both.
>

Yes, we need flexibility. We also need the GS to be able to easily enforce
what can happen.

> XAuth ties them together in the same way that OAuth 2 does, and this is an
> unnecessary restriction that does not add security or simplicity.
>
> *6) Claims at Top Level vs Namespaced *
>
> In XYZ, there is one schema for claims, and they are requested as:
>
>    "claims": {
>        "subject": true,
>        "email": true
>    }
>
> Whereas in XAuth, claims are in their own namespace:
>
>     "claims": {
>         "oidc": {
>             "id_token" : {
>                 "email"          : { "essential" : true },
>                 "email_verified" : { "essential" : true }
>             },
>             "userinfo" : {
>                 "name"           : { "essential" : true },
>                 "picture"        : null
>             }
>         }
>
> In this example, the client is requesting OIDC defined claims, the email
> to be in an ID Token, and the name and picture to be as text. While the XYZ
> schema may be extended, there are already numerous schemas being used. The
> XAuth approach is to support existing and new schemas, rather than pick one
> and/or create another one, and allows a Grant Request to contain claims
> from multiple schemas at the same time.
>
>
> Again, as I have said many times, this part of the request (as is the rest
> of the request) is extensible. The goal of the “claims” object in XYZ was
> to propose a simple, common core. Is this the best set? Probably not, but
> that’s why nothing is final yet, right?
>

Yes, XYZ is extensible. It is not namespaced as XAuth is.

>
> If we wanted to allow for OIDC style claims objects, we have space to do
> exactly that, either as a sub-component of the existing claims object or as
> a new top-level object in the request. This flexibility is important, as
> there are other schemas and other query languages that people might want to
> support, including things like JWM:
>
> https://tools.ietf.org/id/draft-looker-jwm-01.html
>
> And at Mike Jones’s request, I’ve added notes in the current draft of XYZ
> to the places that will be extensible via registry or some other mechanism
> — but the goal was to have everything in there be extensible by reasonable
> mechanisms in ways that will allow innovation to flourish without breaking
> core and common functionality.
>
> I do not understand why you insist on painting XYZ as a static,
> inflexible, and unbending model when it is exactly the opposite. You don’t
> have to externalize every piece of flexibility in order to have it, and I
> really hope that these myths don’t keep getting repeated in the group.
>

All I am doing is comparing what is written. I'm not trying to paint XYZ
anything.

>
>
> *7) No Authorization Type*
>
> Similar to (6), XYZ has a single schema for how to request access to a
> resource. While that schema is extensible, it requires adaption from any
> system with an existing schema. XAuth has a type for each authorization
> request (oauth2, rar), allowing existing schemas and new schemas to be
> supported.
>
>
> This is a ridiculous claim because the RAR format is a back port of the
> XYZ format to an OAuth 2 architecture. If you consider that RAR is
> extensible, then XYZ is extensible by your same definitions. In addition,
> if there are other resource query languages out there beyond these, and we
> can support them just like we would support additional claims query
> languages.
>
> Furthermore, as I’ve said before, XAuth doesn’t allow a clean way to
> define the use of both OAuth 2 scopes and rich requests. XYZ does this by
> allowing scope-style strings and full JSON objects to be specified at the
> same level in the same data structure, so there’s no confusion over how
> they’re grouped or applied. XAuth makes me choose ahead of time to use one
> or the other, effectively at the API level. So I can no longer easily call
> for, say, “login information” (a general scope) along with “transaction
> history for a specific bank account” (a rich data object) in the same
> request. Even RAR handles this better than XAuth by simply letting the
> “scope” parameter also be passed along side the authorization_details
> object, but there are significant complexity issues with this as there
> isn’t a clear way to combine these concepts in the OAuth 2 world. I think
> we can do so much better here, and XYZ proposes one such consistent way to
> do that by defining the scope-equivalent to be a pass-by-reference version
> of the rich object that is passed-by-value. If clients have a shortcut (a
> scope), they can use that; if they need the expressiveness of the resources
> structure, they can do that.
>

Once again it does not seem that you have read the latest draft. XAuth
allows existing OAuth 2 scopes, OR OAuth 2 scopes with RAR, OR a new type
authorization type that works differently.

>
>
> *Summary*
>
> While concerns (3-7) can be addressed in XYZ, (1-2) look fundamental to
> the XYZ architecture.
>
> [1]
> https://tools.ietf.org/html/draft-richer-transactional-authz-08#section-7
>
> [2] https://w3c.github.io/vc-data-model/
>
>
> I’m not sure what you intended to bring up about VC’s in your email,
> because I didn’t see a back-reference to this, but I’m glad you did mention
> it. This is an example of a query, assertion, and proofing data model for
> users that uses a structure and language that is outside of the OIDC world,
> but existing parallel to it.
>

I meant to include [2] as another claim schema in point (6) above. In
XAuth, you will see that "vc" is another object in the "claims" Object.

> I believe our protocol needs to be flexible enough to allow this kind of
> thing on input (the client presenting information about who the user is, as
> well as requesting specific information about the user) and output (the AS
> claiming information about the user), in addition to the client being given
> something that it can then in turn use with another service down the line
> to present user information. The world is moving away from an IdP-driven
> identity model, and we need to keep moving with it and enable it here.
>

We agree on the flexibility. The XAuth proposal is to namespace the schemas
so that adopting existing schemas, or using a new one is straightforward.

>
> Thanks,
>  — Justin
>
>
> ᐧ
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>
>
> ᐧ