Re: [Txauth] Additional implementation

[Fabien Imbault <[e-mail]>]

Hi,

You're spot on with you last comments, we should stay very clear on claims
vs tokens (and indeed they are defined in other working groups). I agree
with that.

What I'm suggesting is that json-ld may be used as a support for providing
context and extendibility capabilities, as it provides a conventional
manner of defining metadata to deliver on the polymorphic feature of the
core protocol.
Request/response (and continuation) endpoints may use this metadata to
adapt their behavior to the capabilities or intent of the other party
(client and AS). The most obvious example is for resources description
("dolphin-metadata" in the XYZ example), to provide semantic context around
common access patterns.

Cheers,

Fabien

Le sam. 4 juil. 2020 à 03:33, Dick Hardt <[e-mail]> a écrit :

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