Re: [Txauth] Additional implementation

Wayne Chang <> Mon, 06 July 2020 16:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2ED823A1629 for <>; Mon, 6 Jul 2020 09:20:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=MmlpLUfz; dkim=pass (2048-bit key) header.b=qeeYjCK6
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cOOtoD_eyzE5 for <>; Mon, 6 Jul 2020 09:20:29 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3188F3A15D9 for <>; Mon, 6 Jul 2020 09:20:29 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 83F685C0219; Mon, 6 Jul 2020 12:20:28 -0400 (EDT)
Received: from imap2 ([]) by compute2.internal (MEProxy); Mon, 06 Jul 2020 12:20:28 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm3; bh=NCo+ZGGqcVzRFzo0FFt4WxLdfWLaKhV 8iYfwmiDdaM4=; b=MmlpLUfzfv33TtCzw/a3xKh929VP5+xivFhlNpAvgogSP0C MCNfAaywif9oaTpXo27e9kVMpYUR+EU/VA6UzlaQtH5rdOs6fh9+3Wf4KZizOzgV j5ujwHS2wyFk1pTDIa9SKED2ajmBnrC6nr+9h+kvarYgQLYDeoSYecmpBQcZmEXN mdQKR/3bSppLTohyyL+xPxhHPZCsterOAxW/+r+sMCtAfQzbtI1DLJ3WaltHDZXp Bzr7of61C7S5bXdAFto5kp+O2TFISIw4hWprQoM5qpheThpTqLoRF0Uv/qjjR2Kp Utvky5Oh4o/GzDLu/W3wd8aLOMokDmlP+0Zr7kg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=NCo+ZG GqcVzRFzo0FFt4WxLdfWLaKhV8iYfwmiDdaM4=; b=qeeYjCK6l7bWH28+9kIUAc DSf6x7+5vpFkB00NWI7UJSNmQwuShsv1WEgDlgH9KEOPQM4HZdOW+cBLpYHBdiQF 4yQ9KZZxERHQNOZveZz+Ns0qcx3YlktQAPJNvC1Diig38P+Kn+398XnXU+sIDyc2 AgKk1GN4VTfcleekVwvzbvt7NznYQPAgMIf/TTwlNov2SAgohbgvh95nsTIL1s+F d/9To2X9e6MkfO5ucua5i9XANl3vnCqFRAusp6J/jaEv8kSIQWgiZ4bk6Pgj3qkZ VhGgI5OLoq/hHFyBbqsedEfrgUaOQDb3UP/emf/SVODiuKtSJcTvKf6ZOYEhXihA ==
X-ME-Sender: <xms:TE8DX1tJfJ6EFgS20cVdR-GKpJR6UUxLN0KBjP4woesAftLryxBaBA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudefgddutdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdghrgih nhgvucevhhgrnhhgfdcuoeifhigtsehfrghsthhmrghilhdrfhhmqeenucggtffrrghtth gvrhhnpeeuieetledtjeegfefhgfffueevgeehfefhudejheeuleejffeugeejffegkeei heenucffohhmrghinhepshhouhhrtggvghhrrghphhdrtghomhdpihgvthhfrdhorhhgne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepfiihtges fhgrshhtmhgrihhlrdhfmh
X-ME-Proxy: <xmx:TE8DX-cZrfZamcqtZfZRlXWhV3EZnpEJME281sNu0_dw25AHBgqZaA> <xmx:TE8DX4zpTbdfw-W_ymun8vfz671uz3nAcHXnUHuuwAuxM0QgNnea-Q> <xmx:TE8DX8Ok8wXREo602T3oW5kGW0AjEq2v3368QaD2tetS8VfeAnl0tg> <xmx:TE8DXyEsouLGsUV0abAc8GUbl3u84Fl8xUh-YwTZyDm3cZpn8hnCWQ>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2F887E00B3; Mon, 6 Jul 2020 12:20:28 -0400 (EDT)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-576-gfe2cd66-fm-20200629.001-gfe2cd668
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
Date: Mon, 06 Jul 2020 12:20:07 -0400
From: "Wayne Chang" <>
To: "Dick Hardt" <>, "Fabien Imbault" <>
Cc: "Benjamin Kaduk" <>,
Content-Type: multipart/alternative; boundary=af21197bf68241e3a6ffb242de2e0207
Archived-At: <>
Subject: Re: [Txauth] Additional implementation
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 06 Jul 2020 16:20:31 -0000

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
> 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 <> 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 <> 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 <>
>>>  > wrote:
>>>  > 
>>>  > > On Thu, Jul 2, 2020 at 7:34 PM Dick Hardt <> wrote:
>>>  > >
>>>  > >> On Wed, Jun 17, 2020 at 3:47 AM Fabien Imbault <>
>>>  > >> 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