Re: [Txauth] Additional implementation

[Fabien Imbault <[e-mail]>]

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 <[e-mail]> 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
> .
>
> 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 <[e-mail]>
> 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
>>
>> On Mon, Jul 6, 2020 at 12:53 AM Benjamin Kaduk <[e-mail]> wrote:
>>
>>> Hi Dick, Fabien,
>>>
>>> Just to clarify on one point, and check whether I'm confused:
>>>
>>> On Fri, Jul 03, 2020 at 06:32:44PM -0700, Dick Hardt wrote:
>>> > On Fri, Jul 3, 2020 at 1:19 AM Fabien Imbault <
>>> [e-mail]>
>>> > wrote:
>>> >
>>> > > On Thu, Jul 2, 2020 at 7:34 PM Dick Hardt <[e-mail]>
>>> wrote:
>>> > >
>>> > >> On Wed, Jun 17, 2020 at 3:47 AM Fabien Imbault <
>>> [e-mail]>
>>> > >> wrote:
>>> >
>>> > >
>>> > >> 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.
>>>
>>> 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
>>>
>>