Subject: [Txauth] Additional implementation

From: Fabien Imbault <[email-masked]>
Date: Wed, 10 Jun 2020 10:56:20 +0200

Hi,

Just to let you know that we started our own implementation of XYZ / XAuth
(and future GNAP).
It's just a first attempt of getting the concepts put into use quickly. We
wanted to have a clear separation between the client and the AS, and
demonstrate the retrieval of a protected resource to make it simpler for
people to understand (even if there's nothing new there).

Here's a quick MVP of xyz. Currently it's just implementing a basic flow,
redirect with callback interaction.
https://github.com/acertio/mvp_xyz
(also working on the same for XAuth, because I sometimes get a bit lost in
discussions between Justin and Dick, really need to get down to the drafts
and write concrete examples to get a sense of what it means).
This is very basic/naive but really gave us some better ideas on what to
test/implement next, and contribute to the discussion.

Note also that our target implementation will be in rust, and we are
currently testing the approach on how to best implement it using a system
oriented language (the fact that nodejs is very web oriented is abstracting
some important aspects in our view).
Our work is available under an MPLv2 licence, and we'll be happy to keep
working on a separate and open reference implementation.

As a last comment, I'd like to say that both XYZ and XAuth are great work,
but it seems we're having 2 competing views, difficult to reconcile. I
believe we can do better.

Following our experiments, I would say:
a) XYZ really makes a new experience possible, and the flow really fixes
common issues in OAuth2. I believe this design idea is of great value, but
the downside is that the written spec doesn't explicitly cover every aspect
yet, so sometimes you have to guess or dig into Justin's implementation.
But making sure we clarify that is also what the working group is there
for, isn't it?
Justin has even put his money where his mouth is by providing
implementations and integrating with legacy software (an old implementation
by mitre), so it's a very good sign that we won't end up with unnecessary
breaking changes.

b) XAuth's spec is written in a more consistent way, which reflects the
fact that is closer to the previous art. There is no reference
implementation (as far as I'm aware) and it comes with the potential
downside of having a more opinionated/prescriptive stance and being much
closer to legacy (for good or worse).

However, I don't think the game of spotting the differences is that
meaningful, and the charter should provide sufficient common ground to
proceed forward despite or thanks to those differences. Otherwise we'll end
up in surprisingly narrow considerations, such as I prefer X because it's
reusing existing schemas. This is something we need to handle when time
comes, but that's really an implementation detail and obviously nobody
thinks we shouldn't reuse things that do work.

A better way would be XYZ concepts challenged by XAuth's rigour (surely
Dick and others would make sure of that) and several iterative
implementations to make sure it does work as intended, as we propose to do.

Fabien

---

From: Dick Hardt <[email-masked]>
Date: Tue, 16 Jun 2020 10:22:49 -0700

Hi Fabien

Thanks for diving in and doing an implementation, and providing your
observations! ... comments inline ...

> test/implement next, and contribute to the discussion.

I'm keen to see an XAuth implementation. Please let me know if there is
anything underspecified that is holding you back.

> by mitre), so it's a very good sign that we won't end up with unnecessary

In which areas did you need to dig into Justin's implementation?

"XYZ really makes a new experience possible" -- do you think the new
experience was not possible in XAuth?

> closer to legacy (for good or worse).

In contrast to OAuth 2, which was a framework, our charter is to deliver a
protocol. IMHO being opinionated and prescriptive simplifies
interoperability or a protocol.

> thinks we shouldn't reuse things that do work.

The intention is not a game of spot the difference, but to discuss
different proposals for providing functionality.

wrt. the schema discussion, one aspect is reusing an existing schema, which
is not an implementation detail, but must be specified. The more
significant point I was trying to make was that we should clearly define
how new schemas are added, and that the claims object should contain only
schema objects, which then contain how to request and respond to identity
claims.

> implementations to make sure it does work as intended, as we propose to do.

I am challenging the XYZ concepts with XAuth! Would be great for you to
provide feedback on the concepts I have challenged. Perhaps after you have
implemented XAuth you can provide an implementation perspective?

/Dick

---

From: Fabien Imbault <[email-masked]>
Date: Wed, 17 Jun 2020 09:44:23 +0200

Hi Dick,

First I'd like to thank you for your work as co-chair, and I think it's
great you will focus on the spec. Very much looking forward to it, there's
ground to make something great.

We are also working on a (partial) XAuth implementation, nothing is holding
back apart from the time to do it. As soon as it's ready, we'll publish it
with comments on our thoughts.
We started with XYZ with a very basic starter, but Justin provided great
comments that we're integrating (though not had too much time since last
Friday to work on it). Will publish an update soon as it clarifies a lot
the intended flow between the client and the AS.
Basically, this initial work is intended as on-going microtests for people
to play with (and better understand, beyond the very people that initially
wrote the spec), and in time we'll work on a more solid GNAP
implementation.

For the rest of your comments, I just think we need a way forward, beyond
both XYZ and XAuth. Either we start from one, and complement with the
other; or we start from basic principles (although that may take
longer...), I don't exactly know which path is best, but what's certain is
that we need to get going.
In all cases, I'm a great believer in having concrete implementations (as
well as docs and compliance tests) to make sure people do understand and
implement the spec as it must (or should, depending on which part).
Just as for the pronunciation ("nap" is fine with me), people can still do
whatever they want, but it's probably best to clarify our intent as much as
we possibly can.

Fabien

On Tue, Jun 16, 2020 at 7:23 PM Dick Hardt <[email-masked]> wrote:

>> Just to let you know that we started our own implementation of XYZ /
>> XAuth (and future GNAP).
>> It's just a first attempt of getting the concepts put into use quickly.
>> We wanted to have a clear separation between the client and the AS, and
>> (also working on the same for XAuth, because I sometimes get a bit lost
>> in discussions between Justin and Dick, really need to get down to the
>> drafts and write concrete examples to get a sense of what it means).
>> As a last comment, I'd like to say that both XYZ and XAuth are great
>> work, but it seems we're having 2 competing views, difficult to reconcile.
>> I believe we can do better.
>>
> wrt. the schema discussion, one aspect is reusing an existing schema,
> which is not an implementation detail, but must be specified. The more

---

From: Fabien Imbault <[email-masked]>
Date: Wed, 17 Jun 2020 12:47:22 +0200

Hi again,

Maybe to already provide a bit more feedback to the spec writers from the
external implementations done so far: I'll take the example of the redirect
flow.
Related parts that I focus on the remaining of this message:
https://oauth.xyz/interaction/
https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-2.1

In XYZ:
- the vocabulary should be updated to reflect the underlying GNAP idea
("grant")
- the discovery mechanism is pretty nice https://oauth.xyz/discovery
- the request is very simple, the client just needs to know the URL of the
grant server. No clientID registration needed, which is good in my opinion
(if we don't need it, we shouldn't include it).
- the fields within request/responses are more examples than complete
specs. The current version shows the intent, but for the external
implementor it's not always straightforward.
- the protocol is very clear on the verifications that should be done
(pretty similar to a PKCE flow idea) -> that's really useful
- the proposal provides some interesting insights in how tokens should be
managed (see https://oauth.xyz/tokens, with a great deal of care on
providing proofs) and more generally we see the proposal integrates/unifies
the advances from many advanced schemes in OAuth (DPoP for instance),
although there's still work to make things crystal clear
- the authentication part has been discussed at
https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz so there's no
real difficulty here (but that needs to be integrated)

in XAuth:
- the vocabulary is quite nice (grant, etc.)
- the proposal is much more detailed on all the required and possible
fields within requests/responses -> so far, although it would require a
detailed study, I haven't spent much time of that since it is fairly close
to previous art, but it will be very useful
- but sometimes I'm not sure it's 100% correct (or at least that it can be
misleading): for instance 7.  *Read Grant* The Client makes an HTTP GET
request to the Grant URI, should be called "Request grant read' in my
opinion, so that we understand it's actually a request.
- it already integrates the authentication part, in line with OIDC
- the suggested protocol is HTTP2, while I don't exactly see why that is
required. HTTP1.1 (with TLS) would be just fine for the proposed scope, and
generally speaking I don't think there's a strict requirement on the
version (I'm working on HTTP3 too which would be a great fit as well, later
on).

Note that I haven't yet read the exchanges between Justin and Dick on the
differences, as I wanted to make my own idea before refining based on their
comments. So I'm probably missing some details as of now.

But it gives the intuition on why I (as an external reader) think both
proposals are complementary and why the concepts are not that different,
except on relatively low details (which matter of course, but at a later
stage). A common starting point seems really feasible -> there's really the
possibility to merge the core ideas quickly, and iterate from there. I
would really favor a very minimal spec on which we can build quickly
(instead of 2 "competing" views, even if as I described earlier there's a
lot of common ground, it requires a lot of effort to get a consistent
picture, and we would benefit from reducing that complexity).

Beyond what I said on the redirect, we could probably benefit from a more
formal definition of the flows (a bit different between the 2 proposals),
as proposed recently by Francis Pouatcha for instance
(interact/decoupled/embedded flows, TBD).

What I'm missing in both proposals (personal opinion):

- I know that JSON is the usual format, but it would be really useful to
complement the schemas with some JSON-LD descriptions as well. It would
ease extensions and interoperability (by avoiding conflicting schemas), and
could even provide a more generic way of representing verifiable
presentations (challenge/nonce associated to a domain for instance). While
most of this work on linked data has been done at W3C, it would add value
to the current proposal so I think we should consider it.

- from an extensibility point of view, I'm not sure it's very useful to
list all possibilities. For instance, as of now, it wouldn't be possible to
use the protocol for constrained devices, so there's no real value in
saying that it could be extended with CoAP (then we need a separate
document, that references the current GNAP rfc). What's more useful to know
if the context of the current document, when you're implementing it, is
what behaviour can really be extended in a fairly straightforward
way, without changing anything in the core spec. For instance, what can I
do with other types of tokens than JWT? Neither proposal is very clear as
to how we would implement extensions in practice.

- from an implementation perspective, it would make sense to decompose the
flow between the Grant Server (GS) and the login/consent part (as done for
instance by ory.sh). This way you would separate the concerns: on one side
you have the HTTP flows (managed by the GS, which can be very optimized
from a backend perspective), but you can delegate/customize the interaction
UI to some agreed dedicated endpoint (typically a JS site). Maybe that's
just a detail which doesn't have its place in the spec, but since it would
change the flow, it might be important to consider, at least as a
possibility/extension.

Fabien

On Wed, Jun 17, 2020 at 9:44 AM Fabien Imbault <[email-masked]>
wrote:

> We are also working on a (partial) XAuth implementation, nothing is
> holding back apart from the time to do it. As soon as it's ready, we'll
> publish it with comments on our thoughts.
>>> Here's a quick MVP of xyz. Currently it's just implementing a basic
>>> flow, redirect with callback interaction.
>> In contrast to OAuth 2, which was a framework, our charter is to deliver
>> a protocol. IMHO being opinionated and prescriptive simplifies