Re: [Txauth] Additional implementation

[Dick Hardt <[e-mail]>]

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