Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5133A00D3 for ; Wed, 10 Jun 2020 07:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHYJ0abMU9s2 for ; Wed, 10 Jun 2020 07:54:29 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 373493A00B2 for ; Wed, 10 Jun 2020 07:54:28 -0700 (PDT) Received: from [192.168.1.14] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 05AEsPF8013500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 10 Jun 2020 10:54:25 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_3A1E12FB-67E6-4372-91D4-507BBD232FF2" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 10 Jun 2020 10:54:25 -0400 In-Reply-To: Cc: txauth@ietf.org To: Dick Hardt References: <44332CBC-83B1-411C-B518-EE2F3D030301@mit.edu> <01A1051E-30AB-419B-A0F1-C9AED6BFA357@mit.edu> <3D57381A-DA98-4DD7-8960-A6D94A643E43@mit.edu> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Txauth] XYZ-08 vs XAuth-08 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2020 14:54:34 -0000 --Apple-Mail=_3A1E12FB-67E6-4372-91D4-507BBD232FF2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 9, 2020, at 4:11 PM, Dick Hardt wrote: >=20 > Comments inline >=20 > Last item will be broken out to new thread. >=20 > On Tue, Jun 9, 2020 at 9:10 AM Justin Richer > wrote: >=20 >=20 >> On Jun 8, 2020, at 5:33 PM, Dick Hardt > wrote: >>=20 >>=20 >>=20 >> On Mon, Jun 8, 2020 at 1:02 PM Justin Richer > wrote: >>=20 >> >>> A GS implementation can decide to only return an authorization from = doing a GET on the AZ URL. Returning only an AZ URL is an option in = XAuth. Similarly, we could do the same for a Grant URI.=20 >>=20 >> And that=E2=80=99s a lot of complex code paths for both the GS and = client to deal with. With more ways that it might happen, the client has = to be prepared for any of them =E2=80=94 and get them all right.=20 >>=20 >> I don't see it being complex. The data either moves by reference or = by value. Both parties will have to enable support by reference. Passing = by value is an optimization so that the client does not have to make an = additional call. >=20 > =E2=80=9CBoth parties will have to enable=E2=80=9D is where the = complexity comes into play. It=E2=80=99s putting a requirement on the = client to anticipate several different ways to get the same information. >=20 > As I understand it, XYZ works the same way. The client may get a = handle to the transaction in an Interaction Response or a Wait Response, = or the client receives a transaction response. >=20 > There could be only one way in XAuth (pass by reference), but I expect = that people will prefer an optimization of pass by value when it can be = done and deal with the complexity that they may get the data in two = different ways, just as in XYZ. It=E2=80=99s not the same. What you=E2=80=99re missing, I believe, is = that this is one of the benefits of having a single endpoint, as XYZ is = defined today. The =E2=80=9Cgrant response=E2=80=9D comes from exactly = one place regardless of where in the transaction it happens. This is why = I think this is something the working group as a whole needs to weigh in = on, to figure out the pros and cons of different designs. I personally = don=E2=80=99t like the complexity, and a definitely don=E2=80=99t like = the restrictions imposed by XAuth today, but there are benefits that = might outweigh and justify that move.=20 > =20 >=20 >>=20 >> >>=20 >>> =20 >>>=20 >>> Using a different URI, optionally, isn=E2=80=99t the problem, and = that could easily be added to the. Removal of the separate handle is the = problem I have with the XAuth approach. >>>=20 >>> In XAuth, the Grant URI is the GS URI + TBD + handle >>>=20 >>> Given we have asymmetric crypto as a requirement, it is unclear what = having two pieces of random signal provide. >>=20 >> Asymmetric crypto is an implementation requirement in both the input = drafts but it isn=E2=80=99t a requirement in the charter, and there are = likely symmetric use cases and key proofing mechanisms that are going to = be desirable for a lot of people. >>=20 >>> =20 >>>=20 >>>> =20 >>>>=20 >>>> Additionally, I find XAuth=E2=80=99s restrictions on the structure = of the Grant URI potentially problematic, namely that it has to start = with the server=E2=80=99s 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=E2=80=99s the = point of dictating how that has to look? >>>>=20 >>>> 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. >>>=20 >>> You still haven=E2=80=99t addressed why you think that this is a = reasonable requirement or assumption here but not when dealing with = long/short URLs for QR codes. What is the difference? >>>=20 >>> Short URLs generally use a short host name as well as a short path.=20= >>>=20 >>> Most REST interfaces have the pattern I am proposing. A mental model = many developers are familiar with.=20 >>=20 >> This is assuming a lot on the part of the GS implementation, still, = and all of my arguments stand.=20 >>=20 >>=20 >> That is not entirely correct. A pre-registered client can still pass = its key by value, and a dynamic client can still use a = (dynamically-acquired) handle. In all cases, the client is identifying = itself by its key. The difference is how the server looks up that key = =E2=80=94 it=E2=80=99s either from the handle, or it=E2=80=99s from the = key value itself.=20 >>=20 >> I don't understand this.=20 >>=20 >> How is the Client authenticating that it is a specific pre-registered = client? >=20 > The client is identified by its key. >=20 > And you think that will be an easy concept for developers to migrate = to from the mental model they have now? And what is the value? I believe = your proposal for other pre-registered clients to migrate was to use the = Client ID as the Key Handle. So the Key Handle may represent any of the = pre-registered clients, but represents each instance of a dynamic = client. Does not seem like it is any different than how a Client ID is = used today. >=20 > Tom has started a new thread on other aspects of this section. Not only do I think OAuth developers can migrate, I think it=E2=80=99s = essential that we do in order to make this useful to non-OAuth = developers. Vast swaths of the internet are already building out = key-based systems, not using OAuth. In my own experience, I can say for = a fact that the awkwardness of needing a client identifier ahead of time = is one of the problems. The fact that there=E2=80=99s a place to use a = legacy client ID within the protocol is a bonus feature, and important = for migration. But it=E2=80=99s even more important that it=E2=80=99s = not=20 And we should look at history before we declare something impossible. We = managed to get web developers away from thinking about accessing an API = with a username and password and toward thinking in terms of accessing = it with a token. This is a shift of the same kind, and an important one = at that. To me, this is one of the important fundamental shifts of this work away = from the limits of OAuth=E2=80=99s models and assumptions, and one of = the ones that will make this work applicable far outside of the space = that OAuth 2 has already carved. I don=E2=80=99t see a compelling reason = to limit ourselves. If your primary goal is to keep OAuth 2 developers safe and happy, then = in all honesty, just keep using OAuth 2. Why wouldn=E2=80=99t you? Use = PAR and RAR and DPoP for advanced functionality. It=E2=80=99s a = combination that, if a bit patched-together, does work. Move to a new = protocol when it does something you can=E2=80=99t do, or it=E2=80=99s = otherwise a better fit for what you=E2=80=99re trying to solve. And when = you=E2=80=99re in a position to move, there=E2=80=99s a migration path. = That doesn=E2=80=99t mean it=E2=80=99s a direct re-use, it means you can = migrate =E2=80=94 move, change =E2=80=94 without tearing absolutely = everything out. But you still need to move, and that=E2=80=99s expected.=20= In all honesty, I think the gap between OAuth 2 and XYZ is less than the = gap between OAuth 1 and OAuth 2, especially if you=E2=80=99re looking at = using OAuth 2 with PAR, RAR, etc. I don=E2=80=99t see a compelling = reason to artificially limit the new protocol with the constraints of = the old, particularly when there=E2=80=99s a migration path between = them. XYZ can make use of some of the familiar pieces of OAuth 2 without = causing all clients to depend on them. That=E2=80=99s the difference = between migration and straight re-use. > >> In XAuth, if the server wants to protect itself from a session = fixation attack in a given request, and it wants to support both = "redirect" and "user_code" modes,=20 >> the server will return only those two modes and not "indirect". The=20= >>=20 >> In XAuth, if the server wants to protect itself from a session = fixation attack in a given request, and it wants to support both = "redirect" and "user_code" modes,=20 >> the server MUST return callback, redirect, and user_code. The client = does not know that the "indirect" mode is not supported, and may try = that. >>=20 >=20 > In XYZ, if the server wants to protect against a session fixation = attack, it will reject a request that doesn=E2=80=99t have a = =E2=80=9Ccallback=E2=80=9D field in it. The AS always gets to choose = which things it supports for any given request. If the client wants to = support both =E2=80=9Credirect=E2=80=9D and =E2=80=9Cuser_code=E2=80=99 = modes AND has the ability to handle session fixation issues, it sends = the =E2=80=9Credirect=E2=80=9D, =E2=80=9Cuser_code=E2=80=99, and = =E2=80=9Ccallback=E2=80=9D fields in its interaction request.=20 >=20 > If the client chooses to present the interaction_url as a scannable = barcode, which is an option if it receives one, it will then get an = error when it tries to do a transaction continue request as the AS = protects itself. Unfortunately the user has scanned the barcode and is = now at the AS. I don't see how the client learns it is not able to do = what I call an "indirect" mode interaction. Would you explain how this = situation is prevented in XYZ? If the client has made a request with =E2=80=9Credirect=E2=80=9D and = =E2=80=9Ccallback=E2=80=9D in its request, and then decides to display = the interaction URL as a scannable code, then the AS will just redirect = to the client=E2=80=99s callback URL when it=E2=80=99s done, whatever = that URL was. If the client sends a =E2=80=9Ccallback=E2=80=9D URL that = it can=E2=80=99t get information from, then that=E2=80=99s a = poorly-written client, isn=E2=80=99t it? If the client can=E2=80=99t get to the information in the callback URL = unless it=E2=80=99s on the same device, then the client isn=E2=80=99t = going to show the user a scannable code to be read by a secondary = device. Why would it? >=20 > >> =20 >>=20 >>>=20 >>> For example:=20 >>>=20 >>> How is a transaction updated?=20 >>> How are separate access tokens refreshed?=20 >>> Refreshing an access token in XYZ returns a full transaction = response per Section 9.3 which refers to Section 8. >=20 > Would you address these questions? Transactions are updated by sending the transaction handle back with = additional information. This is no different from the request made after = a front channel callback, or what would be made in a challenge-response = format. I haven=E2=80=99t written up a way to create a new transaction = building on an old one (which I think is an important advanced use = case), but it would amount to having a separate field in the initial = transaction request to have the transaction handle of the old = transaction in it.=20 Multiple access tokens cannot be refreshed separately in the current = implementation of XYZ. This is a noted gap in the spec, and I=E2=80=99m = open to ideas on how it would be handled. > =20 >>>=20 >>>=20 >>> By using URIs and methods, XAuth has an easy to understand API for = CRUD operations on Grants and Authorizations. >>>=20 >>> = +--------------+-----------+--------+-----------------------------+ >>> | request | http verb | uri | response = | >>> = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D+=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ >>> | Create Grant | POST | GS URI | interaction, wait, or = grant | >>> = +--------------+-----------+--------+-----------------------------+ >>> | List Grants | GET | GS URI | grant list = | >>> = +--------------+-----------+--------+-----------------------------+ >>> | Verify Grant | PATCH | Grant | grant = | >>> | | | URI | = | >>> = +--------------+-----------+--------+-----------------------------+ >>> | Read Grant | GET | Grant | wait, or grant = | >>> | | | URI | = | >>> = +--------------+-----------+--------+-----------------------------+ >>> | Update Grant | PUT | Grant | interaction, wait, or = grant | >>> | | | URI | = | >>> = +--------------+-----------+--------+-----------------------------+ >>> | Delete Grant | DELETE | Grant | success = | >>> | | | URI | = | >>> = +--------------+-----------+--------+-----------------------------+ >>> | Read AuthZ | GET | AZ URI | authorization = | >>> = +--------------+-----------+--------+-----------------------------+ >>> | Update AuthZ | PUT | AZ URI | authorization = | >>> = +--------------+-----------+--------+-----------------------------+ >>> | Delete AuthZ | DELETE | AZ URI | success = | >>> = +--------------+-----------+--------+-----------------------------+ >>> | GS Options | OPTIONS | GS URI | metadata = | >>> = +--------------+-----------+--------+-----------------------------+ >>> | Grant | OPTIONS | Grant | metadata = | >>> | Options | | URI | = | >>> = +--------------+-----------+--------+-----------------------------+ >>> | AuthZ | OPTIONS | AZ URI | metadata = | >>> | Options | | | = | >>> = +--------------+-----------+--------+-----------------------------+ >>> =20 >>=20 >> While this looks good on paper, there are very pragmatic reasons that = many APIs have moved away from purely RESTful patterns over the last = decade, including limitations on what can be sent with GET and DELETE = requests, for example. I don=E2=80=99t think it=E2=80=99s as clean a win = as you=E2=80=99re presenting it, but I think it=E2=80=99s worth checking = out. >>=20 >> Agreed that RESTful does not work for everything. It does look like = it maps well here. >=20 > I disagree that it maps well. I think this is an over-application of a = design pattern and the details will be problematic in implementation. >=20 > What aspect does not map well? >=20 > What do you think will be problematic? >=20 > It seems much simpler to route a request based on URI and verb(XAuth), = then parse and inspect a JSON payload (XYZ) See above. > =20 >=20 >> =20 >>=20 >>>=20 >>>> =20 >>>>=20 >>>> 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=E2=80=99s say, for example, a client can do a = redirect, accept a CIBA-style ping, or do a direct app2app = communication. There=E2=80=99s a natural preference the client will have = here: if it can talk to another app directly, it=E2=80=99ll try that = first. If that doesn=E2=80=99t 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.=20 >>>>=20 >>>> 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. >>>=20 >>> Yes, did you read what I wrote? I think we=E2=80=99re talking past = each other. >>>=20 >>> This is not how XAuth is written currently. The Client can list all = of the modes it wants to use. The Server will return all the modes that = fit in its policy for the Grant Request. Why would the Client need to = make different requests? >>>=20 >>> per >>>=20 >>> = https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-3.4.2 = = =20 >>>=20 >>> The interaction object contains one or more interaction mode objects = per Section 5 >>>=20 >>> Three modes are defined here: >>>=20 >>> https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-5 = >>>=20 >>> More modes may defined in extensions, or in this document. >>=20 >> Yes, this is an improvement, and I=E2=80=99m glad you=E2=80=99re = moving your thinking in this direction. However, it=E2=80=99s still not = as clear how things combine to solve different use cases, and it = conflates the means of getting the user TO the interaction page with the = way of getting them BACK from it. It=E2=80=99s these flexible = combinations that I think are important, and I don=E2=80=99t think XAuth = gets this quite right yet.=20 >>=20 >> I think how the user gets to and from the server is CRITICAL to the = server if it wants to protect itself from a session fixation attack. >> See above where the client does not know what it can actually do that = the server will allow. >=20 > It is critical that the server knows how to protect itself, yes. = It=E2=80=99s not critical that the way there and the way back are = tightly bound to each other in this way. I think that model is limiting. >=20 > What other way back are you envisioning there could be besides a URI = redirect? >=20 > Rolling between mobile apps is a URI redirect. What else could happen? >=20 > I expect there will be new ways of transferring control to a GS, or = that the GS will reach out to the user directly. >=20 Push notifications on a mobile platform, COAP-style subscriptions at the = HTTP layer, messages coming in over a blockchain fabric through a = separate entity=E2=80=A6 I think your view of what a client is and how it could communicate and = interact is limited, and that=E2=80=99s informing XAuth=E2=80=99s = design. > =20 >=20 >> =20 >> >>>=20 >>> It is an OR in that if the client is using the type "oauth_scope", = they cannot have an "authorization_details" attribute, they can only = have "scope" >>>=20 >>> If the client is using the type "oauth_rich", the client MUST = include "authorization_details", and MAY include "scope" >>> =20 >>> I have updated the the doc to better capture that: >>>=20 >>> = https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-3.4.4 = >>>=20 >>> and example 2 now is of type "oauth_rich" >>>=20 >>> = https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-3.2 = >>>=20 >>=20 >> It was not clear to me that both could be sent with that mode, so = thank you for updating that. But the client still has to choose one or = the other up front. Why not have a mechanism that it can send both at = all times? Why have a =E2=80=9Cmode=E2=80=9D type switch at all? XYZ = allows clients to make these combined requests with a single consistent = syntax. >>=20 >> And by completely externalizing this to OAuth 2, I would argue that = we lose an opportunity to more clearly define how resources are = described and used, and we inherit the same combination issues that are = facing RAR today. We can do better because we get to define the context. >>=20 >> This group can define a new syntax if it wants, and it will be = unencumbered by the OAuth 2 and RAR legacy if deployments that want to = use the OAuth 2 and RAR syntax can use them directly. Ie, there can be a = type "gnap" or some such. >=20 >=20 > You did not respond to this response.=20 >=20 What I=E2=80=99m proposing in XYZ is exactly the new syntax that = incorporates both RAR and scope natively by using handles and = polymorphic JSON. Other resource request syntaxes could also be defined = and added. > The next section I have put into a separate email. >=20 > /Dick >=20 > =E1=90=A7 --Apple-Mail=_3A1E12FB-67E6-4372-91D4-507BBD232FF2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = Jun 9, 2020, at 4:11 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Comments inline

Last item will be broken out to new thread.

On Tue, Jun 9, 2020 at 9:10 AM Justin Richer <jricher@mit.edu> = wrote:


On Jun 8, 2020, at 5:33 PM, = Dick Hardt <dick.hardt@gmail.com> wrote:



On Mon, Jun 8, 2020 at 1:02 PM Justin = Richer <jricher@mit.edu> wrote:

<snip>
A GS implementation can decide to = only return an authorization from doing a GET on the AZ URL. Returning = only an AZ URL is an option in XAuth. Similarly, we could do the same = for a Grant URI. 

And that=E2=80=99s a lot = of complex code paths for both the GS and client to deal with. With more = ways that it might happen, the client has to be prepared for any of them = =E2=80=94 and get them all = right. 

I don't see it being complex. The data = either moves by reference or by value. Both parties will have to enable = support by reference. Passing by value is an optimization so that the = client does not have to make an additional = call.

=E2=80=9CBoth parties will have to = enable=E2=80=9D is where the complexity comes into play. It=E2=80=99s = putting a requirement on the client to anticipate several different ways = to get the same information.

As I understand it, = XYZ works the same way. The client may get a handle to the transaction = in an Interaction Response or a Wait Response, or the client receives a = transaction response.

There could be only one way in XAuth (pass by reference), but = I expect that people will prefer an optimization of pass by value when = it can be done and deal with the complexity that they may get the data = in two different ways, just as in = XYZ.

It=E2=80=99s not the same. What you=E2=80=99re = missing, I believe, is that this is one of the benefits of having a = single endpoint, as XYZ is defined today. The =E2=80=9Cgrant response=E2=80= =9D comes from exactly one place regardless of where in the transaction = it happens. This is why I think this is something the working group as a = whole needs to weigh in on, to figure out the pros and cons of different = designs. I personally don=E2=80=99t like the complexity, and a = definitely don=E2=80=99t like the restrictions imposed by XAuth today, = but there are benefits that might outweigh and justify that = move. 

 


 <snip>

 

Using a different URI, optionally, = isn=E2=80=99t the problem, and that could easily be added to the. = Removal of the separate handle is the problem I have with the XAuth = approach.

In XAuth, the Grant URI is the GS = URI + TBD + handle

Given we have asymmetric crypto as = a requirement, it is unclear what having two pieces of random = signal provide.

Asymmetric crypto is an = implementation requirement in both the input drafts but it isn=E2=80=99t = a requirement in the charter, and there are likely symmetric use cases = and key proofing mechanisms that are going to be desirable for a lot of = people.

 

 

Additionally, I find XAuth=E2=80=99s restrictions on the = structure of the Grant URI potentially problematic, namely that it has = to start with the server=E2=80=99s 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=E2=80=99s 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.

You still haven=E2=80=99t = addressed why you think that this is a reasonable requirement or = assumption here but not when dealing with long/short URLs for QR codes. = What is the difference?

Short URLs generally use a short host = name as well as a short path. 

Most REST interfaces have the pattern I = am proposing. A mental model many developers are familiar = with. 

This is assuming a lot on the part of = the GS implementation, still, and all of my arguments = stand. 


That = is not entirely correct. A = pre-registered client can still pass its key by value, and a = dynamic client can still use a (dynamically-acquired) handle. In all = cases, the client is identifying itself by its key. The difference is = how the server looks up that key =E2=80=94 it=E2=80=99s either from the = handle, or it=E2=80=99s from the key value = itself. 

I don't understand this. 

How is the Client authenticating that = it is a specific pre-registered = client?

The client is identified = by its key.

And you think that will be an easy = concept for developers to migrate to from the mental model they have = now? And what is the value? I believe your proposal for other = pre-registered clients to migrate was to use the Client ID as the Key = Handle. So the Key Handle may represent any of the pre-registered = clients, but represents each instance of a dynamic client. Does not seem = like it is any different than how a Client ID is used today.

Tom has started a new = thread on other aspects of this = section.

Not only do I think OAuth developers can migrate, = I think it=E2=80=99s essential that we do in order to = make this useful to non-OAuth developers. Vast swaths of the internet = are already building out key-based systems, not using OAuth. In my own = experience, I can say for a fact that the awkwardness of needing a = client identifier ahead of time is one of the problems. The fact that = there=E2=80=99s a place to use a legacy client ID within the protocol is = a bonus feature, and important for migration. But it=E2=80=99s even more = important that it=E2=80=99s not 

And we should look at history before we declare = something impossible. We managed to get web developers away from = thinking about accessing an API with a username and password and toward = thinking in terms of accessing it with a token. This is a shift of the = same kind, and an important one at that.

To me, this is one of the important fundamental = shifts of this work away from the limits of OAuth=E2=80=99s models and = assumptions, and one of the ones that will make this work applicable far = outside of the space that OAuth 2 has already carved. I don=E2=80=99t = see a compelling reason to limit ourselves.

If your primary goal is to keep OAuth 2 developers = safe and happy, then in all honesty, just keep using OAuth 2. Why = wouldn=E2=80=99t you? Use PAR and RAR and DPoP for advanced = functionality. It=E2=80=99s a combination that, if a bit = patched-together, does work. Move to a new protocol when it does = something you can=E2=80=99t do, or it=E2=80=99s otherwise a better fit = for what you=E2=80=99re trying to solve. And when you=E2=80=99re in a = position to move, there=E2=80=99s a migration path. That doesn=E2=80=99t = mean it=E2=80=99s a direct re-use, it means you can migrate =E2=80=94 = move, change =E2=80=94 without tearing absolutely everything out. But = you still need to move, and that=E2=80=99s expected. 

In all honesty, I think the gap between OAuth 2 = and XYZ is less than the gap between OAuth 1 and OAuth 2, especially if = you=E2=80=99re looking at using OAuth 2 with PAR, RAR, etc. I don=E2=80=99= t see a compelling reason to artificially limit the new protocol with = the constraints of the old, particularly when there=E2=80=99s a = migration path between them. XYZ can make use of some of the familiar = pieces of OAuth 2 without causing all clients to depend on them. = That=E2=80=99s the difference between migration and straight = re-use.

 <snip>
In XAuth, if the server wants to protect itself from a = session fixation attack in a given request, and it wants to support both = "redirect" and "user_code" modes, 
the server = will return only those two modes and not "indirect". The 

In = XAuth, if the server wants to protect itself from a session fixation = attack in a given request, and it wants to support both "redirect" and = "user_code" modes, 
the server MUST return callback, redirect, and = user_code. The client does not know that the "indirect" mode is not = supported, and may try that.


In XYZ, if the server wants to protect = against a session fixation attack, it will reject a request that = doesn=E2=80=99t have a =E2=80=9Ccallback=E2=80=9D field in it. The AS = always gets to choose which things it supports for any given request. If = the client wants to support both =E2=80=9Credirect=E2=80=9D and = =E2=80=9Cuser_code=E2=80=99 modes AND has the ability to handle session = fixation issues, it sends the =E2=80=9Credirect=E2=80=9D, = =E2=80=9Cuser_code=E2=80=99, and =E2=80=9Ccallback=E2=80=9D fields in = its interaction request. 

If the client chooses to = present the interaction_url as a scannable barcode, which is an option = if it receives one, it will then get an error when it tries to do a = transaction continue request as the AS protects itself. Unfortunately = the user has scanned the barcode and is now at the AS. I don't see how = the client learns it is not able to do what I call an "indirect" mode = interaction. Would you explain how this situation is prevented in = XYZ?

If= the client has made a request with =E2=80=9Credirect=E2=80=9D and = =E2=80=9Ccallback=E2=80=9D in its request, and then decides to display = the interaction URL as a scannable code, then the AS will just redirect = to the client=E2=80=99s callback URL when it=E2=80=99s done, whatever = that URL was. If the client sends a =E2=80=9Ccallback=E2=80=9D URL that = it can=E2=80=99t get information from, then that=E2=80=99s a = poorly-written client, isn=E2=80=99t it?

If the client can=E2=80=99t get to the information = in the callback URL unless it=E2=80=99s on the same device, then the = client isn=E2=80=99t going to show the user a scannable code to be read = by a secondary device. Why would it?


<snip>
 


For example: 

How is a transaction = updated? 
How are separate access tokens = refreshed? 
Refreshing an access token in XYZ = returns a full transaction response per Section 9.3 which refers to = Section 8.
<= /div>
Would you address = these questions?

Transactions are updated by sending the = transaction handle back with additional information. This is no = different from the request made after a front channel callback, or what = would be made in a challenge-response format. I haven=E2=80=99t written = up a way to create a new transaction building on an old one (which I = think is an important advanced use case), but it would amount to having = a separate field in the initial transaction request to have the = transaction handle of the old transaction in it. 

Multiple access tokens cannot be refreshed = separately in the current implementation of XYZ. This is a noted gap in = the spec, and I=E2=80=99m open to ideas on how it would be = handled.

 


By using = URIs and methods, XAuth has an easy to understand API for CRUD = operations on Grants and Authorizations.

    =
+--------------+-----------+--------+-----------------------------+
    | request      | http verb | uri    | response                    |
    +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+
    | Create Grant | POST      | GS URI | interaction, wait, or grant |
    +--------------+-----------+--------+-----------------------------+
    | List Grants  | GET       | GS URI | grant list                  |
    +--------------+-----------+--------+-----------------------------+
    | Verify Grant | PATCH     | Grant  | grant                       |
    |              |           | URI    |                             |
    +--------------+-----------+--------+-----------------------------+
    | Read Grant   | GET       | Grant  | wait, or grant              |
    |              |           | URI    |                             |
    +--------------+-----------+--------+-----------------------------+
    | Update Grant | PUT       | Grant  | interaction, wait, or grant |
    |              |           | URI    |                             |
    +--------------+-----------+--------+-----------------------------+
    | Delete Grant | DELETE    | Grant  | success                     |
    |              |           | URI    |                             |
    +--------------+-----------+--------+-----------------------------+
    | Read AuthZ   | GET       | AZ URI | authorization               |
    +--------------+-----------+--------+-----------------------------+
    | Update AuthZ | PUT       | AZ URI | authorization               |
    +--------------+-----------+--------+-----------------------------+
    | Delete AuthZ | DELETE    | AZ URI | success                     |
    +--------------+-----------+--------+-----------------------------+
    | GS Options   | OPTIONS   | GS URI | metadata                    |
    +--------------+-----------+--------+-----------------------------+
    | Grant        | OPTIONS   | Grant  | metadata                    |
    | Options      |           | URI    |                             |
    +--------------+-----------+--------+-----------------------------+
    | AuthZ        | OPTIONS   | AZ URI | metadata                    |
    | Options      |           |        |                             |
    =
+--------------+-----------+--------+-----------------------------+
<= /div>
 

While this looks good on = paper, there are very pragmatic reasons that many APIs have moved away = from purely RESTful patterns over the last decade, including limitations = on what can be sent with GET and DELETE requests, for example. I don=E2=80= =99t think it=E2=80=99s as clean a win as you=E2=80=99re presenting it, = but I think it=E2=80=99s worth checking = out.

Agreed that RESTful does not work for everything. It does = look like it maps well here.

I disagree that it maps = well. I think this is an over-application of a design pattern and the = details will be problematic in = implementation.

What aspect does not map = well?

What do = you think will be problematic?

It seems much simpler to route a = request based on URI and verb(XAuth), then parse and inspect a JSON = payload (XYZ)

See above.

 

 


 

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=E2=80=99s say, for example, a client can do a redirect, accept = a CIBA-style ping, or do a direct app2app communication. There=E2=80=99s = a natural preference the client will have here: if it can talk to = another app directly, it=E2=80=99ll try that first. If that doesn=E2=80=99= 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.

Yes, did you read what I wrote? I think = we=E2=80=99re talking past each = other.

This is not how XAuth is written = currently. The Client can list all of the modes it wants to use. The = Server will return all the modes that fit in its policy for the Grant = Request. Why would the Client need to make different requests?

per

https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#secti= on-3.4.2  

The interaction object contains one or more interaction mode = objects per Section 5

Three modes are defined here:

https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#secti= on-5

More modes may defined in extensions, or in this = document.

Yes, this is an improvement, and I=E2=80=99= m glad you=E2=80=99re moving your thinking in this direction. However, = it=E2=80=99s still not as clear how things combine to solve different = use cases, and it conflates the means of getting the user TO the = interaction page with the way of getting them BACK from it. It=E2=80=99s = these flexible combinations that I think are important, and I don=E2=80=99= t think XAuth gets this quite right = yet. 

I think how the user gets to and from = the server is CRITICAL to the server if it wants to protect itself from = a session fixation attack.
See above where the = client does not know what it can actually do that the server will = allow.

It is critical that the server knows = how to protect itself, yes. It=E2=80=99s not critical that the way there = and the way back are tightly bound to each other in this way. I think = that model is limiting.

What other way back are you envisioning = there could be besides a URI redirect?

Rolling between mobile apps is a URI = redirect. What else could happen?

I expect there will be new ways of = transferring control to a GS, or that the GS will reach out to the user = directly.


Push notifications on a mobile platform, = COAP-style subscriptions at the HTTP layer, messages coming in over a = blockchain fabric through a separate entity=E2=80=A6

I think your view of what a client is and how it = could communicate and interact is limited, and that=E2=80=99s informing = XAuth=E2=80=99s design.

 

 
<snip>

It is an OR in that if the client is = using the type "oauth_scope", they cannot have an = "authorization_details" attribute, they can only have "scope"

If the client is using = the type "oauth_rich", the client MUST = include "authorization_details", and MAY include "scope"
 
I have updated the the doc to = better capture that:

https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#secti= on-3.4.4

and example 2 now is of type "oauth_rich"

https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#secti= on-3.2


It was not clear to me that both could = be sent with that mode, so thank you for updating that. But the client = still has to choose one or the other up front. Why not have a mechanism = that it can send both at all times? Why have a =E2=80=9Cmode=E2=80=9D = type switch at all? XYZ allows clients to make these combined requests = with a single consistent syntax.

And by completely externalizing this to = OAuth 2, I would argue that we lose an opportunity to more clearly = define how resources are described and used, and we inherit the same = combination issues that are facing RAR today. We can do better because = we get to define the context.

This group can define a = new syntax if it wants, and it will be unencumbered by the OAuth 2 and = RAR legacy if deployments that want to use the OAuth 2 and RAR syntax = can use them directly. Ie, there can be a type "gnap" or some = such.

You did not respond to = this response. 


What I=E2=80=99m proposing in XYZ is exactly the = new syntax that incorporates both RAR and scope natively by using = handles and polymorphic JSON. Other resource request syntaxes could also = be defined and added.

The next section I have put into a separate email.

/Dick

3D""=E1=90=A7

= --Apple-Mail=_3A1E12FB-67E6-4372-91D4-507BBD232FF2--