Subject: [Txauth] New version of XYZ Draft

From: Justin Richer <[email-masked]>
Date: Thu, 16 Jul 2020 17:52:46 -0400

Hi all,

I’ve updated the XYZ draft specification. Since the publication tools are currently locked prior to the upcoming virtual meeting, I have published it online here:

https://oauth.xyz/draft-richer-transactional-authz <https://oauth.xyz/draft-richer-transactional-authz>

This represents a pretty significant refactoring of the specification, hopefully to make the concepts and capabilities easier to understand. The core protocol is largely the same as before, but there are a number of serious updates:

 - Continuation requests happen at a URL returned in the TX response. The “handle” is still sent as one of the input values here, since the handle can also be used it other contexts.
 - Tokens now can include the resources they are issued for
 - Tokens can have an optional management URI for rotation and revocation.
 - “claims” has been removed in favor of “subject” dealing directly with identifiers and assertions
 - the “user” request and response now align with identifiers and assertions
 - Extensions and registries are more clearly enumerated throughout the document
 - DID-related items have been excised in deference to a future possible extension
 - Added a “pushback” mechanism to complement the “callback” mechanism
 - Simplified dynamic handle returns and access tokens based on developer feedback (basically we dropped a bunch of “what if” stuff that nobody used or liked, like SHA3 hashes for bearer tokens)

I’ve also updated the interactive examples on https://oauth.xyz/ <https://oauth.xyz/> to match this new draft. Hopefully it’s consistent with the draft text.

I have not yet, however, updated any of the implementations of XYZ to take the elements of new syntax into account, so there might be some more changes prior to the IETF meeting as I realize what terrible mistakes I’ve made when doing that. :) 

Feedback, as always, is welcomed, and thanks to everyone who’s provided input to the project to date. 

 — Justin

---

From: Dick Hardt <[email-masked]>
Date: Fri, 17 Jul 2020 10:10:10 -0700

Hey Justin,

Glad to see that you are aligning on having URIs for the access tokens and
the "grant".

While the token URI is unique to the token, you have not done the same for
a "grant", but have a handle and a non-unique URI.

Why not have a unique grant URI similar to the token URI? (a combination of
the handle and a non-unique URI) -- this is then both the identifier, and
the URL for "management"?

Glad to see you have excised the DID references. I don't think the common
use cases are well established there currently.

I have LOTS of feedback on your interaction changes, that I'll post later
on, and hope that others have feedback on those as well.

/Dick

On Thu, Jul 16, 2020 at 2:52 PM Justin Richer <[email-masked]> wrote:

> Hi all,
>
> I’ve updated the XYZ draft specification. Since the publication tools are
> currently locked prior to the upcoming virtual meeting, I have published it
> online here:
>
> https://oauth.xyz/draft-richer-transactional-authz
>
> This represents a pretty significant refactoring of the specification,
> hopefully to make the concepts and capabilities easier to understand. The
> core protocol is largely the same as before, but there are a number of
> serious updates:
>
>  - Continuation requests happen at a URL returned in the TX response. The
> “handle” is still sent as one of the input values here, since the handle
> can also be used it other contexts.
>  - Simplified dynamic handle returns and access tokens based on developer
> feedback (basically we dropped a bunch of “what if” stuff that nobody used
> or liked, like SHA3 hashes for bearer tokens)
>
> I’ve also updated the interactive examples on https://oauth.xyz/ to match
> this new draft. Hopefully it’s consistent with the draft text.
>
> I have not yet, however, updated any of the implementations of XYZ to take
> the elements of new syntax into account, so there might be some more
> changes prior to the IETF meeting as I realize what terrible mistakes I’ve
> made when doing that. :)
>
> --
> Txauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth
>

---

From: Justin Richer <[email-masked]>
Date: Fri, 17 Jul 2020 17:34:10 -0400

Most of these are changes I’ve wanted to do for quite some time and finally had opportunity to make the edits. As I said below, the core protocol really hasn’t changed in nature, but hopefully it’s easier to understand with it laid out in this way. 

All of these are points that I’ve made previously on the list in discussions, but to answer your questions directly:

- Mapping items to separate URLs has been on XYZ’s radar since well before it was proposed in Xauth, so this is bringing some of that into the concrete system. I still need to implement it to see how well it works in practice.

- The need to rotate the reference handle as well as use it externally (the “extend a request” method) both call for having an identifier separate from the access URL. It also allows an AS more freedom in how it manages its endpoints, and aligns with the desire to push more information into the ongoing request after the initial phase. I’d actually rather the access token management move in that direction, using the token itself as the artifact, but I couldn’t do that and still use the DELETE method for revocation. So that’s an engineering challenge that I think the group should discuss, and decide whether it’s worth having the “DELETE” verb semantics and having that restriction placed on the AS as a consequence.

- The DID work is likely better suited for an extension, and always has been. But it was worth having in previous revisions for discussion purposes, especially as a point around how a non-HTTP interaction method would work. I expect to see DIDCOMM, CHAPI, WebAuthN, and other interaction methods in the extensions landscape of GNAP, usable alongside the others. 

And a final point, the interaction setup hasn’t really changed, so I’m curious to hear what you think has changed there. Even with a couple new capabilities on the way there (short_uri and app) and back (pushback), It’s structurally and conceptually identical to previous revisions.

 — Justin

> On Jul 17, 2020, at 1:10 PM, Dick Hardt <[email-masked]> wrote:
> 
> Hey Justin,
> 
> Glad to see that you are aligning on having URIs for the access tokens and the "grant".
> 
> While the token URI is unique to the token, you have not done the same for a "grant", but have a handle and a non-unique URI.
> 
> Why not have a unique grant URI similar to the token URI? (a combination of the handle and a non-unique URI) -- this is then both the identifier, and the URL for "management"?
> 
> Glad to see you have excised the DID references. I don't think the common use cases are well established there currently.
> 
> I have LOTS of feedback on your interaction changes, that I'll post later on, and hope that others have feedback on those as well.
> 
> /Dick
> 
> 
> 
> 
> 
> On Thu, Jul 16, 2020 at 2:52 PM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> Hi all,
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>

---

From: Dick Hardt <[email-masked]>
Date: Fri, 17 Jul 2020 15:46:48 -0700

XYZ is looking a lot more like XAuth, similar to how XAuth has shifted
towards XYZ.

I have implemented separate URIs for grants and authorizations, and it
worked really well.

All 3 of the new capabilities are problematic. Perhaps you did not notice
that there no longer is a short_uri in XAuth? As I recall, you were opposed
to the short URI that was in the earlier drafts of XAuth. In my XAuth
implementation, I show QR codes in the CLI app. Have you checked out my
implementation? Have you implemented a QR code? I found that the string did
not need to be nearly as short as it has in the past.

I still don't understand the requirement to rotate the reference handle. I
read over the pointer you provided last time we discussed it, and
responded, but I have not heard back from you on that.

ᐧ

On Fri, Jul 17, 2020 at 2:36 PM Justin Richer <[email-masked]> wrote:

> Most of these are changes I’ve wanted to do for quite some time and
> finally had opportunity to make the edits. As I said below, the core
> protocol really hasn’t changed in nature, but hopefully it’s easier to
> understand with it laid out in this way.
>
> All of these are points that I’ve made previously on the list in
> discussions, but to answer your questions directly:
>
> - Mapping items to separate URLs has been on XYZ’s radar since well before
> it was proposed in Xauth, so this is bringing some of that into the
> concrete system. I still need to implement it to see how well it works in
> practice.
>
> - The need to rotate the reference handle as well as use it externally
> (the “extend a request” method) both call for having an identifier separate
> from the access URL. It also allows an AS more freedom in how it manages
> its endpoints, and aligns with the desire to push more information into the
> ongoing request after the initial phase. I’d actually rather the access
> token management move in that direction, using the token itself as the
> artifact, but I couldn’t do that and still use the DELETE method for
> revocation. So that’s an engineering challenge that I think the group
> should discuss, and decide whether it’s worth having the “DELETE” verb
> semantics and having that restriction placed on the AS as a consequence.
>
> - The DID work is likely better suited for an extension, and always has
> been. But it was worth having in previous revisions for discussion
> purposes, especially as a point around how a non-HTTP interaction method
> would work. I expect to see DIDCOMM, CHAPI, WebAuthN, and other interaction
> methods in the extensions landscape of GNAP, usable alongside the others.
>
> And a final point, the interaction setup hasn’t really changed, so I’m
> curious to hear what you think *has* changed there. Even with a couple
> new capabilities on the way there (short_uri and app) and back (pushback),
> It’s structurally and conceptually identical to previous revisions.
>
>  — Justin
>
> Why not have a unique grant URI similar to the token URI? (a combination
> of the handle and a non-unique URI) -- this is then both the identifier,
> and the URL for "management"?
>
>> I’ve also updated the interactive examples on https://oauth.xyz/ to
>> match this new draft. Hopefully it’s consistent with the draft text.
>>
>> I have not yet, however, updated any of the implementations of XYZ to
>> take the elements of new syntax into account, so there might be some more

---

From: Justin Richer <[email-masked]>
Date: Sat, 18 Jul 2020 10:55:11 -0400

I really don’t see them as shifting towards each other so much as it is them adapting and changing based on ongoing efforts. As such I’ve modified XYZ not to make it “look more like XAuth”, but rather to hopefully improve it in some measurable dimensions. So if you wonder why it doesn’t “look even more like XAuth” it’s because I don’t think that such changes would be improvements — in fact, even with recent improvements, I think there are a still a lot of issues with XAuth’s design and assumptions. XYZ can, I’m sure, also be improved.

The goal here isn’t to take two projects and make them look the same. The goal here is to make one protocol, GNAP, with the best ideas and elements engineered into it that we, as a working group, can. It’s not about one input proposal winning over another, it’s about improving our understanding of all the use cases and possible solutions and coming up with the best specification possible. Making things better should always be the goal. Progress should always be the goal. 

But we aren’t here to build XYZ or XAuth. We’re here to build GNAP and decide what GNAP looks like. XYZ’s structure and design is the best I’ve been able to make it so far, and it should be our goal as a WG to move past either XYZ or XAuth and build GNAP even better than any of that.

 — Justin

> On Jul 17, 2020, at 6:46 PM, Dick Hardt <[email-masked]> wrote:
> 
> XYZ is looking a lot more like XAuth, similar to how XAuth has shifted towards XYZ. 
> 
> I have implemented separate URIs for grants and authorizations, and it worked really well.
> 
> All 3 of the new capabilities are problematic. Perhaps you did not notice that there no longer is a short_uri in XAuth? As I recall, you were opposed to the short URI that was in the earlier drafts of XAuth. In my XAuth implementation, I show QR codes in the CLI app. Have you checked out my implementation? Have you implemented a QR code? I found that the string did not need to be nearly as short as it has in the past. 
> 
> I still don't understand the requirement to rotate the reference handle. I read over the pointer you provided last time we discussed it, and responded, but I have not heard back from you on that.
> 
> 
> ᐧ
> 
> On Fri, Jul 17, 2020 at 2:36 PM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> On Jul 17, 2020, at 1:10 PM, Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hey Justin,
>>

---

From: Dick Hardt <[email-masked]>
Date: Sat, 18 Jul 2020 17:58:38 -0700

Justin: how about we let the chairs drive WG conversations on the
goals, and we focus on the technical discussion?

In addition to my questions and observations earlier, here is my feedback
on the new capabilities in XYZ:

2.5.2. Redirect to an Arbitrary Short URL

This looks the same as 2.5.1 except it is short. My concern with both of
these is the AS has no signal on the mode chosen by the client/user. It
could be a redirect on the same device, or decoupled, where the user is now
on a different device. In 2.5.3 you justify a new URL because the AS may
want a different URL for an app. I think that is even more significant
between an on device redirect, and a decoupled experience. By having
different URLs for the different modes in XAuth, the AS can ensure the one
in a decoupled mode is short enough to be scanned if decoupled is
supported. In other words, the mode dictates if it should be short enough
to be scanned.

2.5.3 Open an Application-specific URL

What are you intending "app" to mean? I can think of a device where the
client can open a URL, and a URL could not be associated with an
application on the device. Are you thinking the client will do some
detection if a specific app is available on the device? What if the app is
not on the device? Most platforms don't provide any probing on what other
apps are on a device, so there is no mechanism to detect if the app is
present prior to launching. Is that what you are expecting?

2.5.5. Receive an HTTP Direct Callback

What use cases require this functionality? Contrary to SecEvent, where both
push and poll are specified because a receiver may not be able to have a
public endpoint, the AS has a public endpoint for the client to call. In
GNAP, the client can poll the AS. Why have both?

/Dick

On Sat, Jul 18, 2020 at 7:55 AM Justin Richer <[email-masked]> wrote:

> I really don’t see them as shifting towards each other so much as it is
> them adapting and changing based on ongoing efforts. As such I’ve modified
> XYZ not to make it “look more like XAuth”, but rather to hopefully improve
> it in some measurable dimensions. So if you wonder why it doesn’t “look
> even more like XAuth” it’s because I don’t think that such changes would be
> improvements — in fact, even with recent improvements, I think there are a
> still a lot of issues with XAuth’s design and assumptions. XYZ can, I’m
> sure, also be improved.
>
> The goal here isn’t to take two projects and make them look the same. The
> goal here is to make one protocol, GNAP, with the best ideas and elements
> engineered into it that we, as a working group, can. It’s not about one
> input proposal winning over another, it’s about improving our understanding
> of all the use cases and possible solutions and coming up with the best
> specification possible. Making things better should always be the goal.
> Progress should always be the goal.
>
> But we aren’t here to build XYZ or XAuth. We’re here to build GNAP and
> decide what GNAP looks like. XYZ’s structure and design is the best I’ve
> been able to make it so far, and it should be our goal as a WG to move past
> either XYZ or XAuth and build GNAP even better than any of that.
>
>  — Justin
>
>> - Mapping items to separate URLs has been on XYZ’s radar since well
>> before it was proposed in Xauth, so this is bringing some of that into the
>> While the token URI is unique to the token, you have not done the same
>> for a "grant", but have a handle and a non-unique URI.
>>
>>> I’ve updated the XYZ draft specification. Since the publication tools
>>> are currently locked prior to the upcoming virtual meeting, I have
>>> published it online here:
>>>
>>>  - Continuation requests happen at a URL returned in the TX response.
>>> The “handle” is still sent as one of the input values here, since the
>>> handle can also be used it other contexts.
>>>  - Simplified dynamic handle returns and access tokens based on
>>> developer feedback (basically we dropped a bunch of “what if” stuff that
>>> nobody used or liked, like SHA3 hashes for bearer tokens)
>>>

---

From: Denis <[email-masked]>
Date: Mon, 20 Jul 2020 11:33:29 +0200

Hi Justin,

Since you mentioned "Feedback, as always, is welcomed", hereafter are a 
few comments:

1) The trust relationships are not described: Example : A trusts B for 
some behaviour C.

2) There is no figure to illustrate the various exchanges and to 
indicate whether they are mandatory or optional.

3) The user consent is not addressed.

4) The draft states:

9 Discovery

            By design, the protocol minimizes the need for any 
pre-flight discovery. To begin a transaction, the RC only needs to know
            the transaction endpoint of the AS, and everything else can 
be negotiated dynamically.

If the RC wants to optimize its calls to the AS, it MAY send an HTTP 
OPTIONS request to the transaction endpoint to retrieve
            the server's discovery information.

At the beginning, the client has to clue about what will be requested by 
the RS. Furthermore what will be requested by the RS
will be dependent upon the operation that will be attempted at the RS 
and /the requested information may change at any point of time/.

As long as the client does not know which attributes from which AS(*s*) 
will be needed to perform a given operation on a RS,
the client may not know which AS(*s*) to contact. So the client shall, 
at least once, contact the RS.

Another point is about the RS discovery information. Some RSs, may only 
be willing to disclose some parts of their discovery information
to authenticated users/client applications and some other parts of their 
discovery information to users or client applications that have
already successfully performed some operation(s). The disclosed 
discovery information usually depends both upon the operation that is 
requested
and upon which operation(s) has/have already been successfully 
performed. The case where the discovery information is static and publicly
disclosed should be considered as a specific case of the general case.

5) A Client is not requesting one or more access tokens for itself, but 
on behalf of a user or a client application. Users and client applications
may have an account on the AS, but not Clients. A Client is trusted by 
its user or by its client application to interface with ASs and RSs.

At this time, there is no trust relationship between a Client and an AS 
... unless there is a desire to consider the use of secure elements
by users.

6) The model seems to be limited to the case where RSs have a 
relationship with one and only one AS (i.e. it is a mono-domain 
environment)
and seems to be not applicable nor scalable over the Internet with 
millions of RSs trusting thousands of ASs.

Section 2.1.2 called "Requesting Multiple Access Tokens" provides an 
example for two access tokens. However, it is not explained how
such mechanism would be able to obtain multiple access tokens from more 
than a single AS.

7) "By design", the protocol mandates to tell to the AS which RS will be 
accessed and which operations will be attempted.

This places the AS in an perfect position to act as Big Brother: the AS 
will be able to trace which operations are likely to be performed by
either a user or a client application, on which RS and at which instant 
of time. In addition, if artificial intelligence (AI) is used by the AS or
by a third party to which this information is communicated, this leaves 
the gate wide opened to a lot of undisclosed usages "behind the scenery".

Since it is not possible to be confident that ASs will never perform 
some additional tasks "behind the scenery", there is the need to prevent 
ASs
to behave in an inappropriate manner. Unfortunately, the proposed 
architecture is unable to provide this property.

8) Section 14 (Privacy considerations) mentions:

TBD: There are a lot of privacy considerations to add.

Indeed, in particular, readers should be warned that this protocol 
allows the AS to trace/log which operations are likely to be performed
by every user or client application, on which RS, and at which instant 
of time.

Denis

> hopefully to make the concepts and capabilities easier to understand. 
> The core protocol is largely the same as before, but there are a 
> number of serious updates:
>
> developer feedback (basically we dropped a bunch of “what if” stuff 
> that nobody used or liked, like SHA3 hashes for bearer tokens)
>
> take the elements of new syntax into account, so there might be some 
> more changes prior to the IETF meeting as I realize what terrible 
> mistakes I’ve made when doing that. :)
>

---

From: Justin Richer <[email-masked]>
Date: Mon, 20 Jul 2020 07:26:31 -0400

Hi Dick,

I think it should be pretty uncontroversial that the goal of the GNAP working group is to produce the GNAP protocol. But I’m still glad to see you’re interested in focusing on technical discussions. 

Answers to the individual points inline.

> On Jul 18, 2020, at 8:58 PM, Dick Hardt <[email-masked]> wrote:
> 
> Justin: how about we let the chairs drive WG conversations on the goals, and we focus on the technical discussion?
> 
> In addition to my questions and observations earlier, here is my feedback on the new capabilities in XYZ:
> 
> This looks the same as 2.5.1 except it is short. My concern with both of these is the AS has no signal on the mode chosen by the client/user. It could be a redirect on the same device, or decoupled, where the user is now on a different device. In 2.5.3 you justify a new URL because the AS may want a different URL for an app. I think that is even more significant between an on device redirect, and a decoupled experience. By having different URLs for the different modes in XAuth, the AS can ensure the one in a decoupled mode is short enough to be scanned if decoupled is supported. In other words, the mode dictates if it should be short enough to be scanned.

The differences between a “coupled/decoupled” experience are not controlled by the “redirect/short_redirect/app” parameters, but by the “callback/pushback” parameters. The first three are parameters that determine some of the ways that the client can get :to: the AS, while the others are ways the client can get :back: from the AS. They are not tied together like they are in Xauth. 

Which combinations are available is up to the client’s request, since, after all, the client is the piece of software that knows what it can do, not the AS. The AS isn’t in a position to guess what the client is going to do with the information it gets back, it can only respond to the request for information that the client sends. If a client displays a URL to the user as a QR code, it’s probably not going to send a “callback”, for example. If an AS determines that it doesn’t want to support that “decoupled” mode for a given request, it can reject it for lack of a “callback” parameter. The reason for this decoupling 

And as I’m sure you saw in my editor’s note, I’m not convinced that the short_redirect is worth it as a separate option, even though the semantics are pretty clear here. As I said in the last discussion we had on this topic, I’ve implemented a QR code based on a full redirect URI and did not find it problematic. You made a compelling argument that the AS would potentially have different generation rules for short and long, and wouldn’t want to use a short one unless it needed to. It seemed to be a simple enough addition to put in this revision.

> What are you intending "app" to mean? I can think of a device where the client can open a URL, and a URL could not be associated with an application on the device. Are you thinking the client will do some detection if a specific app is available on the device? What if the app is not on the device? Most platforms don't provide any probing on what other apps are on a device, so there is no mechanism to detect if the app is present prior to launching. Is that what you are expecting?

You can detect if an app (any app) is going to handle a URL on some platforms. This mechanism not only lets an AS have different URLs for app launching and web-based interaction, and it lets the client optimize the experience instead of the awkward fall-through that we have with OAuth2’s app2app communication today. Furthermore, as I’m sure you saw in my editor’s note, there’s probably going to be additional pieces of information passed in this case. I’ve talked with a couple different groups who are using distributed storage mechanisms to communicate between components. In that case, this will probably have more information in it than a single URL, but I didn’t want to conjecture what that would look like, thus the note.

> What use cases require this functionality? Contrary to SecEvent, where both push and poll are specified because a receiver may not be able to have a public endpoint, the AS has a public endpoint for the client to call. In GNAP, the client can poll the AS. Why have both?
> 

Why limit the client to only callbacks? The callback means “there’s an HTTP endpoint that the user’s browser gets to” whereas pushback means “there’s an HTTP endpoint that the user’s browser can’t get to”. Both are reasonable, and should be combinable with any of the options for getting a user to the AS, above. There are likely to be other options as well, since we already see them in the wild (CIBA’s push mode, for instance). 

 — Justin

> /Dick
> 
> 
> 
> On Sat, Jul 18, 2020 at 7:55 AM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> On Jul 17, 2020, at 6:46 PM, Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Dick Hardt <[email-masked]>
Date: Mon, 20 Jul 2020 11:54:42 -0700

On Mon, Jul 20, 2020 at 4:26 AM Justin Richer <[email-masked]> wrote:

> Hi Dick,
>
> I think it should be pretty uncontroversial that the goal of the GNAP
> working group is to produce the GNAP protocol. But I’m still glad to see
> you’re interested in focusing on technical discussions.
>
> The differences between a “coupled/decoupled” experience are not
> controlled by the “redirect/short_redirect/app” parameters, but by the
> “callback/pushback” parameters. The first three are parameters that
> determine some of the ways that the client can get :to: the AS, while the
> others are ways the client can get :back: from the AS. They are not tied
> together like they are in Xauth.
>
> Which combinations are available is up to the client’s request, since,
> after all, the client is the piece of software that knows what it can do,
> not the AS. The AS isn’t in a position to guess what the client is going to
> do with the information it gets back, it can only respond to the request
> for information that the client sends. If a client displays a URL to the
> user as a QR code, it’s probably not going to send a “callback”, for
> example. If an AS determines that it doesn’t want to support that
> “decoupled” mode for a given request, it can reject it for lack of a
> “callback” parameter. The reason for this decoupling
>

Looks like you might have not finished this sentence ... but you are
missing my point.

As noted below, the client may not know what it can do until it tries.

The user will often be the one that decides the actual flow that is
started. If the AS has an app, the user will want to use the device with
the AS, which may not be the device the client is on. The client can show a
QR code for the user to scan with their phone, or it can do a redirect to
the browser and get redirected back. The AS does not know which flow is
happening if the URL provided can do either of those.

I described this in:

https://mailarchive.ietf.org/arch/msg/txauth/qOF5Wl3uYQ9rdzEz7ORftYAAHc4/

>
> And as I’m sure you saw in my editor’s note, I’m not convinced that the
> short_redirect is worth it as a separate option, even though the semantics
> are pretty clear here. As I said in the last discussion we had on this
> topic, I’ve implemented a QR code based on a full redirect URI and did not
> find it problematic. You made a compelling argument that the AS would
> potentially have different generation rules for short and long, and
> wouldn’t want to use a short one unless it needed to. It seemed to be a
> simple enough addition to put in this revision.
>
>
> You can detect if an app (any app) is going to handle a URL on some
> platforms. This mechanism not only lets an AS have different URLs for app
> launching and web-based interaction, and it lets the client optimize the
> experience instead of the awkward fall-through that we have with OAuth2’s
> app2app communication today. Furthermore, as I’m sure you saw in my
> editor’s note, there’s probably going to be additional pieces of
> information passed in this case. I’ve talked with a couple different groups
> who are using distributed storage mechanisms to communicate between
> components. In that case, this will probably have more information in it
> than a single URL, but I didn’t want to conjecture what that would look
> like, thus the note.
>

I'm still not sure what you mean by app. Are you thinking only
mobile/tablet? PC? Media streaming device?

On iOS, the ability for an app to detect if a URL will be handled is
significantly limited. Last I checked, you could have 5 URLs in your app to
check. Apple locked it down to improve privacy.

FYI: On iOS, an app can attempt to open a deep link for an app and set a
flag so that the browser will NOT open the URL in the browser if the the
app is not installed. So the client can try opening another app, and if it
is not there, take another course of action, but it would know that until
it tries to open the other app.

> What use cases require this functionality? Contrary to SecEvent, where
> both push and poll are specified because a receiver may not be able to have
> a public endpoint, the AS has a public endpoint for the client to call. In
> Why limit the client to only callbacks? The callback means “there’s an
> HTTP endpoint that the user’s browser gets to” whereas pushback means
> “there’s an HTTP endpoint that the user’s browser can’t get to”. Both are
> reasonable, and should be combinable with any of the options for getting a
> user to the AS, above. There are likely to be other options as well, since
> we already see them in the wild (CIBA’s push mode, for instance).
>

"Why limit the client?"

This is a security protocol. More ways to do the same thing increases the
attack surface. It also increases  complexity / or lowers
interoperability.  The AS either needs to support ALL the mechanisms, or
there may not be interop if the client and AS don't support a common
mechanism.

ᐧ