Re: [Txauth] Additional implementation

[Dick Hardt <[e-mail]>]

Hi Fabien, sorry for the late reply

Comments and questions inserted ...

On Wed, Jun 17, 2020 at 3:47 AM Fabien Imbault <[e-mail]>
wrote:
<snip>

>
> 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).
>

Which proposal was that?


>
> 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.
>

I'm not understanding how JSON-LD would fit in. Would you provide an
example?


>
> - 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.
>

In XAuth I refer to CoAP not as an extension, but as an one example of
other client authentication mechanisms. While it only applies to CoAP, I
think it is useful to call out how we intend GNAP to be extended.

Just like OAuth 2.0, the access token is opaque to the client, and it is
not specified, so I'm confused what you mean by "other types of tokens than
JWT"?




>
> - 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.
>

Is the interaction UI not part of the GS though? I agree that an
implementation can decompose those, but that sounds like an implementation
choice of the GS, and not something that requires standardization. I agree
that we want to anticipate the decomposition.* Is there a change in the
flow that would make that easier?

*One of the reasons I favor using URIs and methods for the different
functionality of the GS API is that it is easy for a router to route a
request to different components of the GS.

/Dick

>