Subject: Re: [Txauth] Additional implementation

From: Dick Hardt <[email-masked]>
Date: Thu, 2 Jul 2020 10:33:24 -0700

Hi Fabien, sorry for the late reply

Comments and questions inserted ...

On Wed, Jun 17, 2020 at 3:47 AM Fabien Imbault <[email-masked]>
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

---

From: Fabien Imbault <[email-masked]>
Date: Fri, 3 Jul 2020 10:19:34 +0200

Thanks Dick.

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

>> (interact/decoupled/embedded flows, TBD).

FI : I'll try to find it back.

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

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.

> think it is useful to call out how we intend GNAP to be extended.

FI : isn't the charter already covering this?

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

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.

> request to different components of the GS.

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

---

From: Dick Hardt <[email-masked]>
Date: Fri, 3 Jul 2020 18:32:44 -0700

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

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

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.

> FI : isn't the charter already covering this?

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

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

> on, because it changes details in the interaction), and the rest stays the

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

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

:)

---

From: Fabien Imbault <[email-masked]>
Date: Sun, 5 Jul 2020 14:47:29 +0200

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 <[email-masked]> a écrit :

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

---

From: Justin Richer <[email-masked]>
Date: Sun, 5 Jul 2020 15:15:04 -0400

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 <[email-masked]> 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 <[email-masked] <mailto:[email-masked]>> a écrit :
> 
> 
> On Fri, Jul 3, 2020 at 1:19 AM Fabien Imbault <[email-masked] <mailto:[email-masked]>> wrote:
> Thanks Dick. 
> 
> On Thu, Jul 2, 2020 at 7:34 PM Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
> On Wed, Jun 17, 2020 at 3:47 AM Fabien Imbault <[email-masked] <mailto:[email-masked]>> 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?
> 
> - 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 <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 <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 <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. 
> 
> 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"?
> 
> 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. 
> 
> *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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 5 Jul 2020 15:53:43 -0700

Hi Dick, Fabien,

Just to clarify on one point, and check whether I'm confused:

> what I would call a claims, which per above are defined somewhere else.

My understanding was that macaroons, at least, were complete tokens that
incorporate (at least by reference) multiple claims.  So a macaroon and a
JWT would be analogous in that sense (container holding many claims).  I'm
not sure whether the same holds for a linked data proof (or if it's just a
way to represent a single claim), though.

Am I confused?

Thanks,

Ben

---

From: Fabien Imbault <[email-masked]>
Date: Mon, 6 Jul 2020 10:01:16 +0200

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 <[email-masked]> 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 Wed, Jun 17, 2020 at 3:47 AM Fabien Imbault <
>>>> [email-masked]> wrote:
>>>> <snip>
>>>>
>>>>>
>> 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
>>>>> - 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
>>>> 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"?
>>>>
>> 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: Fabien Imbault <[email-masked]>
Date: Mon, 6 Jul 2020 10:19:03 +0200

Writing too fast, with an iteration of unrelated examples, did not convey
the right message. Sorry if it wasn't clear and confusing. We indeed need
to differentiate between bearer tokens (e.g. JWT, macaroons or even simple
cookies, etc.) and identity claims (e.g. OIDC claims, linked data proofs,
etc.).
I only wanted to say that we need to take into account that there might be
a variety of formats defined elsewhere. Not only OIDC (for claims) + JWT
(for access tokens).

Regarding JWT vs macaroons : I would say that JWT are additive, while
macaroons are organized around caveats (so they're subtractive in a sense).
But indeed they are both used in similar settings.

Hope that clarifies.
Fabien

On Mon, Jul 6, 2020 at 12:53 AM Benjamin Kaduk <[email-masked]> wrote:

> is
> to

---

From: Dick Hardt <[email-masked]>
Date: Mon, 6 Jul 2020 09:12:51 -0700

Fabien: it would be interesting to see how you think JSON-LD could be used
in the protocol if you have some ideas on that. In XAuth, I am explicit
that there are different formats / schema for tokens and claims. There is
no default, so it is clear how additional formats can be requested and
returned.

Ben: I think that token formats such as macaroons are out of scope of GNAP,
or at least the core protocol. The key feature of macaroons is the ability
to further restrict the authorization. An interesting idea, but depends on
a shared secret, and I have not heard of deployments. In a quick google on
macaroons, I came across this talk from Gopher Con
https://about.sourcegraph.com/go/gophercon-2018-an-over-engineering-disaster-with-macaroons
.

Justin: good to see we are on the same page on all your points. I'd add
that we should consider what JSON is used in the protocol to minimize or
eliminate any impedance mismatch between JSON and CBOR.

/Dick

On Mon, Jul 6, 2020 at 1:19 AM Fabien Imbault <[email-masked]>
wrote:

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

---

From: "Wayne Chang" <[email-masked]>
Date: Mon, 06 Jul 2020 12:20:07 -0400

Hi, just wanted to chime in that in the W3C credentials ecosystem, the JWT vs. JSON-LD proofs debate has raged on and consumed a lot of everyone's time. There are a lot of industry stakeholders who are skittish around requirements to adopt unfamiliar standard, and for some large companies involved in that ecosystem JWTs are more familiar than JSON-LD. For the Verifiable Credentials spec in particular, the authors decided to support both and were careful to ensure this possibility.

This might be a decision better made higher up in the stack than what GNAP is trying to accomplish.

On Mon, Jul 6, 2020, at 12:12 PM, Dick Hardt wrote:
> Fabien: it would be interesting to see how you think JSON-LD could be used in the protocol if you have some ideas on that. In XAuth, I am explicit that there are different formats / schema for tokens and claims. There is no default, so it is clear how additional formats can be requested and returned.
> 
> Ben: I think that token formats such as macaroons are out of scope of GNAP, or at least the core protocol. The key feature of macaroons is the ability to further restrict the authorization. An interesting idea, but depends on a shared secret, and I have not heard of deployments. In a quick google on macaroons, I came across this talk from Gopher Con https://about.sourcegraph.com/go/gophercon-2018-an-over-engineering-disaster-with-macaroons.
> 
> Justin: good to see we are on the same page on all your points. I'd add that we should consider what JSON is used in the protocol to minimize or eliminate any impedance mismatch between JSON and CBOR.
> 
> /Dick
> 
> On Mon, Jul 6, 2020 at 1:19 AM Fabien Imbault <[email-masked]> wrote:
>> Writing too fast, with an iteration of unrelated examples, did not convey the right message. Sorry if it wasn't clear and confusing. We indeed need to differentiate between bearer tokens (e.g. JWT, macaroons or even simple cookies, etc.) and identity claims (e.g. OIDC claims, linked data proofs, etc.).
>> I only wanted to say that we need to take into account that there might be a variety of formats defined elsewhere. Not only OIDC (for claims) + JWT (for access tokens).
>> 
>> Regarding JWT vs macaroons : I would say that JWT are additive, while macaroons are organized around caveats (so they're subtractive in a sense). But indeed they are both used in similar settings. 
>> 
>> Hope that clarifies.
>> Fabien
>> 
>>>  > what I would call a claims, which per above are defined somewhere else..
>>>

---

From: Dick Hardt <[email-masked]>
Date: Mon, 6 Jul 2020 09:26:53 -0700

Agreed.

For those that don't know Wayne, he is pretty involved in the VC efforts.

On Mon, Jul 6, 2020 at 9:20 AM Wayne Chang <[email-masked]> wrote:

> Hi, just wanted to chime in that in the W3C credentials ecosystem, the JWT
> vs. JSON-LD proofs debate has raged on and consumed a lot of everyone's
> time. There are a lot of industry stakeholders who are skittish around
> requirements to adopt unfamiliar standard, and for some large companies
> involved in that ecosystem JWTs are more familiar than JSON-LD. For the
> Verifiable Credentials spec in particular, the authors decided to support
> both and were careful to ensure this possibility.
>
> Ben: I think that token formats such as macaroons are out of scope of
> GNAP, or at least the core protocol. The key feature of macaroons is the
> ability to further restrict the authorization. An interesting idea, but
> depends on a shared secret, and I have not heard of deployments. In a quick
> google on macaroons, I came across this talk from Gopher Con

---

From: Fabien Imbault <[email-masked]>
Date: Mon, 6 Jul 2020 18:30:00 +0200

OK with that. The priority should be on the core of the protocol anyway.
Fabien

Le lun. 6 juil. 2020 à 18:27, Dick Hardt <[email-masked]> a écrit :

>> Hi, just wanted to chime in that in the W3C credentials ecosystem, the
>> JWT vs. JSON-LD proofs debate has raged on and consumed a lot of everyone's
>> Fabien: it would be interesting to see how you think JSON-LD could be
>> used in the protocol if you have some ideas on that. In XAuth, I am
>> explicit that there are different formats / schema for tokens and claims.
>> There is no default, so it is clear how additional formats can be requested
>> and returned.
>>
>> I only wanted to say that we need to take into account that there might
>> be a variety of formats defined elsewhere. Not only OIDC (for claims) + JWT
>> (for access tokens).
>>

---

From: Fabien Imbault <[email-masked]>
Date: Mon, 6 Jul 2020 18:40:05 +0200

Hi Dick,

Yes, when that's ready I'll share some examples (but again, we don't intend
to ignite lengthy debates, see previous answer -> let's keep it as an aside
experiment, as food for thought).

As for macaroons, it's used quite extensively in production within some
blockchain implementations (lightning for instance) and on our side we have
a variant without a shared secret. But here again, we don't need to discuss
that further, as long as we allow for the possibility to use other types
than JWT (which we use also of course).

Thanks.

Fabien

---

From: Justin Richer <[email-masked]>
Date: Mon, 6 Jul 2020 13:15:37 -0400

Fabien,

I think macaroons could be an interesting technology to apply in GNAP as an option for key proofing, for both client->AS and client->RS calls. Since they’re ultimately about tying a key to a data payload, I can see how they would be useful in both cases. I don’t think they’d be a core technology requirement for GNAP though, since flexibility on key presentation is one of the core issues that GNAP is looking to address. I would be interested to see how macaroons would apply here, perhaps as an alternative alongside JWT.

Dick, I’m unaware of anything in JSON that can’t be directly expressed in CBOR. The reverse is not true, but that won’t pose a problem for GNAP. 

 — Justin

> On Jul 6, 2020, at 12:40 PM, Fabien Imbault <[email-masked]> wrote:
> 
> Hi Dick,
> 
> Yes, when that's ready I'll share some examples (but again, we don't intend to ignite lengthy debates, see previous answer -> let's keep it as an aside experiment, as food for thought). 
> 
> As for macaroons, it's used quite extensively in production within some blockchain implementations (lightning for instance) and on our side we have a variant without a shared secret. But here again, we don't need to discuss that further, as long as we allow for the possibility to use other types than JWT (which we use also of course). 
> 
> Thanks. 
> 
> Fabien 
> 
> 
> Le lun. 6 juil. 2020 à 18:13, Dick Hardt <[email-masked] <mailto:[email-masked]>> a écrit :
> Fabien: it would be interesting to see how you think JSON-LD could be used in the protocol if you have some ideas on that. In XAuth, I am explicit that there are different formats / schema for tokens and claims.. There is no default, so it is clear how additional formats can be requested and returned.
> 
> Ben: I think that token formats such as macaroons are out of scope of GNAP, or at least the core protocol. The key feature of macaroons is the ability to further restrict the authorization. An interesting idea, but depends on a shared secret, and I have not heard of deployments. In a quick google on macaroons, I came across this talk from Gopher Con https://about.sourcegraph.com/go/gophercon-2018-an-over-engineering-disaster-with-macaroons <https://about.sourcegraph.com/go/gophercon-2018-an-over-engineering-disaster-with-macaroons>.
> 
> On Mon, Jul 6, 2020 at 1:19 AM Fabien Imbault <[email-masked] <mailto:[email-masked]>> wrote:
> Writing too fast, with an iteration of unrelated examples, did not convey the right message. Sorry if it wasn't clear and confusing. We indeed need to differentiate between bearer tokens (e.g. JWT, macaroons or even simple cookies, etc.) and identity claims (e.g.. OIDC claims, linked data proofs, etc.).
> On Mon, Jul 6, 2020 at 12:53 AM Benjamin Kaduk <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Dick, Fabien,
>