Re: [Txauth] Additional implementation

[Fabien Imbault <[e-mail]>]

Thanks Dick.

Likewise, comments inserted (marked with "FI").

On Thu, Jul 2, 2020 at 7:34 PM Dick Hardt <[e-mail]> wrote:

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

FI : I'll try to find it back.

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

FI : when it comes to extendibility, JSON-LD and JSON schemas could work
together to provide a more explicit information on the type of information
we're handling. You'll find a comparison at
https://w3c.github.io/vc-imp-guide/#benefits-of-json-ld-and-ld-proofs with
standard JWT. In practice, this comes handy as a basis for verified
credentials, would clarify the OIDC semantics and disambiguate the meaning
of specific tokens (see for instance the discussion at
https://www.rfc-editor.org/rfc/rfc8417.html#section-4 on "Preventing
Confusion between SETs and Other JWTs").
https://w3c.github.io/vc-imp-guide/#extending-jwts provides interesting
examples.


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

FI : isn't the charter already covering this?

>
> 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"?
>
> FI : I mean, for instance, linked data proofs, macaroons, and so on.

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

FI : I agree with you on the principle. We're currently testing that to
make sure the standard is supporting these kind of implementation choice.
In XYZ, it means changing the URI for the interaction, having an additional
nonce for the interact server (maybe we can remove that constraint later
on, because it changes details in the interaction), and the rest stays the
same.

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

FI : yes, and that's something interesting that we'll need to discuss
further.

>
> /Dick
>
>>