Re: [GNAP] DID as sub_id or assertion?

Justin Richer <jricher@mit.edu> Wed, 10 March 2021 21:14 UTC

Return-Path: <jricher@mit.edu>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC713A1859 for <txauth@ietfa.amsl.com>; Wed, 10 Mar 2021 13:14:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id piwrAlXmD-M7 for <txauth@ietfa.amsl.com>; Wed, 10 Mar 2021 13:14:50 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39D863A1853 for <txauth@ietf.org>; Wed, 10 Mar 2021 13:14:50 -0800 (PST)
Received: from [192.168.1.22] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 12ALEl1Z005935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 10 Mar 2021 16:14:47 -0500
From: Justin Richer <jricher@mit.edu>
Message-Id: <C862A32F-0902-449F-9E59-2C0612F761DE@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_AB04426E-673D-4634-B37A-6D7D084FDCF0"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Wed, 10 Mar 2021 16:14:47 -0500
In-Reply-To: <CAJmmfSTDRzq+5yyhB1Godwp9uC3QF0nzm_3dkq9SvYor=BBkGQ@mail.gmail.com>
Cc: Fabien Imbault <fabien.imbault@gmail.com>, GNAP Mailing List <txauth@ietf.org>
To: Tobias Looker <tobias.looker@mattr.global>
References: <CAM8feuQ5Q1LrGtniCH3WN5gyf6QhBa-9e+2kzaV0fxzA5D5m7w@mail.gmail.com> <B3A02C1B-5DF6-46AE-B806-8DBBF5F6B701@mit.edu> <CAM8feuRqF90PSbcg_C2jEKjQhP8rpJbJR+9AW_ALqO0CzzaJSg@mail.gmail.com> <CAJmmfSTDRzq+5yyhB1Godwp9uC3QF0nzm_3dkq9SvYor=BBkGQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/XXOVAXRQKWxbGXVXNtJHWVJuwBY>
Subject: Re: [GNAP] DID as sub_id or assertion?
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: GNAP <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Mar 2021 21:14:52 -0000

> 
> > Just a quick comment: an assertion in option 2 is not "the fact the identifier is resolvable to cryptographic material that can be used to validate cryptographic assertions". It is merely a statement by the AS that "the subject corresponding to the reference has a DID" ("has" is the assertion here). 
> 
> Yes I understand to drill down on this more though couldn't the entire request made by the client to the AS also be considered to be an assertion? Therefore the "sub_ids" request element is an assertion by the client about who it believes the subject to be identified as? If this is true then to me the "assertions" request element is there for assertions that parties other than the client are making about the subject (e.g an id_token).
>  

That’s my reading of it, on a wider sense. The assertions in the “assertions” part of the request have been given to the client by some other party, and the client is passing them along to the AS to say “this is who I believe is here right now”. It’s up to the AS to decide if it trusts that. Now around that, the client itself is making a larger statement to the AS and signed with the client instance key, so in a way the request is a kind of assertion. (it’s not really a separable unit of data so I wouldn’t go quite that far, when you drill into it.) But yes, in that context the “sub_ids” and “assertions” are both elements in the “assertion” the client instance is making to the AS about who’s there.

 — Justin