Re: [Txauth] Additional implementation

[Dick Hardt <[e-mail]>]

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 <[e-mail]> 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.
>
> 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 <[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
>
> --
> Txauth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>
>
>