Re: [Txauth] Additional implementation

[Dick Hardt <[e-mail]>]

On Fri, Jul 3, 2020 at 1:19 AM Fabien Imbault <[e-mail]>
wrote:

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

It appears that you are proposing the JSON-LD be used in claims? Am I
correct? Or is there somewhere it would be used in the Grant Request JSON?

My understanding of the charter is the GNAP is a transport for claims, and
that those would be defined somewhere else. OpenID Connect and Verified
Credentials are good examples. The query for a claims similarly would be
defined somewhere else.


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

Yes, but most people that are not in the WG don't read the charter. :)


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

I see. When I read 'token', I think of access tokens. You are referring to
what I would call a claims, which per above are defined somewhere else.


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

I'd be interested in the details on how you are implementing it!


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