Re: [Txauth] Additional implementation

[Fabien Imbault <[e-mail]>]

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

> 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 <[e-mail]> wrote:
>
>> Hi Fabien
>>
>> Thanks for diving in and doing an implementation, and providing your
>> observations! ... comments inline ...
>>
>>
>> On Wed, Jun 10, 2020 at 1:56 AM Fabien Imbault <[e-mail]>
>> wrote:
>>
>>> 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.
>>>
>>
>> I'm keen to see an XAuth implementation. Please let me know if there is
>> anything underspecified that is holding you back.
>>
>>
>>>
>>> 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.
>>>
>>
>> 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?
>>
>>
>>>
>>> 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).
>>>
>>
>> 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.
>>
>>
>>>
>>> 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.
>>>
>>
>> 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.
>>
>>
>>
>>>
>>> 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.
>>>
>>
>> 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
>>
>