Re: [Txauth] Additional implementation

[Fabien Imbault <[e-mail]>]

Hi Justin,

My experience is that JSONLD is much simpler than RDF (which looks much
more alien indeed) and, if done right, wouldn't necessarily be a burden.
But of course, we'd have to demonstrate the added value.

In any case, I agree that CoAP is a very different issue, and not something
I would consider an extension in the sense discussed here. So I agree 100%
on that, as well as on the links with other WG.

Maybe we could start with some concrete examples of what we would encounter
as potential extensions (of course we wouldn't get the full list, but it
might help to test a few variants).

Cheers.

Fabien

On Sun, Jul 5, 2020 at 9:15 PM Justin Richer <[e-mail]> wrote:

> Getting the extensibility right is going to be one of the most important
> things we need to try to balance in GNAP. I’ve worked with JSONLD on a few
> different things, and overall I’m not a fan of it for managing things like
> extensibility. It’s one of those technologies that works great if you’re
> already using it for everything, but it’s a huge learning curve if you’re
> not in the space at all. Instead I would rather we see extensibility
> managed at the JSON level, instead of putting this kind of up-front burden
> of understanding on developers.
>
> In XYZ, for example, you can add new items to the top of the request and
> response (along side “key”, “resources”, “user”, “access_token”, and the
> like), and these all get their own semantics. Additionally, you can extend
> the inner parts of the protocol, like the “interaction” section of the
> request can have new interaction capabilities, and the key section can have
> new proofing mechanisms. And perhaps most importantly, the “resources”
> sections can have items that are specific to a given API, since all APIs
> are potentially different and GNAP shouldn’t make assumptions about how
> they’re structured. The extensibility of all of these can be managed
> without using a formal schema language like JSONLD. We can define core
> elements in the GNAP spec, and allow extension on a registry, for example.
> Or we could use a name spacing mechanism for some things like the resources
> where we expect a lot of variability.
>
> But not everything outside of our core fits this extension category. I
> don’t see CoAP as an extension, for example, because it’s a replacement for
> the whole HTTP/JSON layer, not just the authentication/key-proofing
> portions. I don’t think it makes sense to have GNAP be so abstracted away
> from HTTP/JSON that we end up with a model/binding style specification, and
> that sentiment is built into the proposed charter. An aside, you could do a
> COSE-style signature as a proof mechanism, or a CWK key format, and those
> would both be extensions to GNAP, since they could be communicated over the
> same base protocol.
>
> And finally, there are going to be parts of the protocol that are
> controlled by other working groups and efforts. For instance, someone might
> want to make it possible to return identity information or resource
> information directly in the token response, but that’s outside of what GNAP
> is here for. We have agreement to return identifiers for users (so, things
> like an issuer/subject pair, an email address, a phone number, etc), but
> not profile information or other identity components.
>
> We’ve got a difficult and important thing to balance here: we need to have
> enough detail in the protocol that it’s usable without having to defer to
> other groups or documentation (ie, you shouldn’t need a profile of GNAP to
> be able to run GNAP), but we need to be flexible enough in our structures
> to accommodate new ways of working and doing things, especially when we’re
> looking at things that OAuth 2 is too rigid to handle well, like flexible
> interaction methods.
>
>  — Justin
>
> On Jul 5, 2020, at 8:47 AM, Fabien Imbault <[e-mail]>
> wrote:
>
> 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
>>>>
>>>>> --
> Txauth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>
>
>