Re: [GNAP] DID as sub_id or assertion?

Fabien Imbault <fabien.imbault@gmail.com> Wed, 17 March 2021 02:35 UTC

Return-Path: <fabien.imbault@gmail.com>
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 E0E043A179A for <txauth@ietfa.amsl.com>; Tue, 16 Mar 2021 19:35:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.086
X-Spam-Level:
X-Spam-Status: No, score=-2.086 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_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 PQuCNYse-Kov for <txauth@ietfa.amsl.com>; Tue, 16 Mar 2021 19:35:07 -0700 (PDT)
Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B5D43A1799 for <txauth@ietf.org>; Tue, 16 Mar 2021 19:35:06 -0700 (PDT)
Received: by mail-il1-x12e.google.com with SMTP id t6so93244ilp.11 for <txauth@ietf.org>; Tue, 16 Mar 2021 19:35:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GEGq8u3wmRgYVjzUEVjNVyjkent6/K3c5j5YxDuCylU=; b=YculYAVsFIWlJzsYSIvNiOLrvdKty3BnPa8szw0LPYCasPaLT5EfFXApgLFYXbihpV wSkcqhJ0fkaZIE4pJneG7p9/33YkEahKbEPVUr2rMy8z3D8VLIARvdMi1KjVvbcYDolq /A7IQnhJUO1qrWySMFOzvbiHQ+p8ehFLyjpkGlqRPwQT199xBC0zf8tFh7qEAmoXw70n brFybuQ1TdOn3/KzSeDPNHh0uM+YV++GXB/lb4EV698KpuJN6tyshVtobllxWKO8UPaC fcH42tDMYoTNNeTlOS9mcgp5CkZVWcFB7G0VdhFCT5aPd45Pp7MjjgjF6MM6MVA71hcS oXUg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GEGq8u3wmRgYVjzUEVjNVyjkent6/K3c5j5YxDuCylU=; b=hNKc/absEM3DA0stJKdirjDcfdH3Wyr61dSeCJCGY/2fnlu4ZI1QwGQgWfqFt6L7xx s6FaB6od1TZ+JBF/lkGDDkJzCSBcp7WCYZQjszVlrGILDfzWunY4sNDqooiOCK4FkbEZ ljW5o3s+uZduUxEup3C8qvEISxOHcvpnvgZ4zGboZyG0YyuN+4elgtCo2fi1+vRfMm1b SLs5aZp/CuFRIcNWuFecdfvYRQ3/8qHb7VIOoFdnwTtKPhCRgkD7KrHGG7culHafTPV6 kPgTuVyYv83sNdsxokMq4B3JLkC0xyNezLGL12u17wJzYf5UHA5T2A/ob4nCyYu1mntH VDlg==
X-Gm-Message-State: AOAM530sE7AlX/E3V56Nv+WwDTDD5fVVHaYOsCfnVHlSIDEHJxzMfCTg xQnosY2C6YOUaD1YaDt03DD4aMRwkEdEb3CuSfM=
X-Google-Smtp-Source: ABdhPJw/f7I0DuHlIqR5VbTrzqNDqapQhOe21eyVachGHklpwZERAC+mssZ3tUJA2vKqB2YD/qwxhoVDEY0Iur+vVqE=
X-Received: by 2002:a92:d84f:: with SMTP id h15mr6226185ilq.178.1615948505278; Tue, 16 Mar 2021 19:35:05 -0700 (PDT)
MIME-Version: 1.0
References: <CAM8feuQ5Q1LrGtniCH3WN5gyf6QhBa-9e+2kzaV0fxzA5D5m7w@mail.gmail.com> <B3A02C1B-5DF6-46AE-B806-8DBBF5F6B701@mit.edu> <CAM8feuRuCyKGCDNYXP_gwc=wk986q6m_-DDOcXR8T9k+LdoX9g@mail.gmail.com> <CAM8feuRHQJF6sWGBcvt41kH6V6fwXK0-O15aUgvRRiK9q8vefA@mail.gmail.com> <CAJmmfSSY03c1nn3qtQDhY+Zk490d++zftyftSWPOGPdgPOnkag@mail.gmail.com> <CAM8feuTSWko8q+Agn+0+tLmSAOG6NYH_dMCV697NLna1U-Sxew@mail.gmail.com> <CANYRo8immAFJ08pvd00U6zT6-zRsrHkJ28NuKyC28Fdx=F=USQ@mail.gmail.com>
In-Reply-To: <CANYRo8immAFJ08pvd00U6zT6-zRsrHkJ28NuKyC28Fdx=F=USQ@mail.gmail.com>
From: Fabien Imbault <fabien.imbault@gmail.com>
Date: Wed, 17 Mar 2021 03:34:50 +0100
Message-ID: <CAM8feuQbDJfPqym-2VAb4VyDuL8rm_Yk-sGyrb8_qAapUBtEuw@mail.gmail.com>
To: Adrian Gropper <agropper@healthurl.com>
Cc: Tobias Looker <tobias.looker@mattr.global>, GNAP Mailing List <txauth@ietf.org>, Justin Richer <jricher@mit.edu>
Content-Type: multipart/alternative; boundary="000000000000a1efac05bdb254f3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/6w1DCdDXQjSVdskZ-QeWWa27K5A>
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, 17 Mar 2021 02:35:12 -0000

Hi Adrian,

As the name suggests, it's an identifier for the subject (and so,
hypothetically, a DID to identify the subject). The text indeed concerns
the subject as the RO, as it is known to the AS.

But it's easy to make shortcuts, because often we end-up dealing with is
user = end-user = RO = subject.

Fabien

Le mer. 17 mars 2021 à 03:10, Adrian Gropper <agropper@healthurl.com> a
écrit :

> I'm late to this conversation and confused by Tobias' use of End-User (his
> caps) and subject. Are we talking about a DID for the subject, the
> end-user, or both?
>
> To be clear, in my mind, the subject is in control of policies and
> capabilities at the GNAP AS. The end-user is in control of a client or user
> agent and a request to the AS. The end-user and client may or may not have
> any prior relationship with the AS.
>
> Adrian
>
> On Tue, Mar 16, 2021 at 10:00 PM Fabien Imbault <fabien.imbault@gmail.com>
> wrote:
>
>> Hi Tobias,
>>
>> Not yet (none of the current sub_ids require additional parameters) but
>> if DIDs do get added to subject identifiers, then it's certainly something
>> we would have to support.
>>
>> There's already a very basic version of that, but only to chose the main
>> type (now called "format" in latest draft 07 of SECEVENT), with
>> subject_types_supported in the discovery.
>>
>> Thanks for the heads up, it's worth creating an issue or putting a note
>> in some existing issue to not forget looking into that.
>>
>> Cheers
>> Fabien
>>
>>
>> Le mer. 17 mars 2021 à 01:01, Tobias Looker <tobias.looker@mattr.global>
>> a écrit :
>>
>>> Hi,
>>>
>>> This is probably out of scope for the current conversation but has any
>>> thought been had on how the client instance could communicate additional
>>> options around what subject identifier types it supports for cases where
>>> the client instance will perhaps be required to conduct additional
>>> processing on the artifacts returned by the AS? As an example if the AS
>>> chose to identify the subject (End-User) using a DID and wanted to include
>>> an additional cryptographic assertion that showed it controls keys
>>> appropriately associated to the DID, then the client may have wanted to
>>> communicate some information up front in their request to ensure they can
>>> perform this additional processing, such as the signature suites it
>>> supports and in the context of DIDs potentially which DID methods it is
>>> capable of resolving?
>>>
>>> Thanks,
>>> [image: Mattr website] <https://mattr.global>
>>> *Tobias Looker*
>>> Mattr
>>> +64 (0) 27 378 0461
>>> tobias.looker@mattr.global
>>> [image: Mattr website] <https://mattr.global> [image: Mattr on LinkedIn]
>>> <https://www.linkedin.com/company/mattrglobal> [image: Mattr on Twitter]
>>> <https://twitter.com/mattrglobal> [image: Mattr on Github]
>>> <https://github.com/mattrglobal>
>>> This communication, including any attachments, is confidential. If you
>>> are not the intended recipient, you should not read it - please contact me
>>> immediately, destroy it, and do not copy or use any part of this
>>> communication or disclose anything about it. Thank you. Please note that
>>> this communication does not designate an information system for the
>>> purposes of the Electronic Transactions Act 2002.
>>>
>>>
>>> On Sat, Mar 13, 2021 at 9:26 PM Fabien Imbault <fabien.imbault@gmail.com>
>>> wrote:
>>>
>>>> Hi Justin,
>>>>
>>>> A last word on end-user! =RO (again just as food for thought).
>>>>
>>>> As soon as hints.automated is set to true, it takes priority over
>>>> async, which means it's the same model as the one you describe : the AS has
>>>> precedence over any other remote contact.
>>>>
>>>> So that confirms the global view that the AS is the one with the
>>>> authority, and that it might know more than the client.
>>>>
>>>> Cheers
>>>> Fabien
>>>>
>>>> Le jeu. 11 mars 2021 à 11:44, Fabien Imbault <fabien.imbault@gmail.com>
>>>> a écrit :
>>>>
>>>>> Hi Justin,
>>>>>
>>>>> I think that's interesting:
>>>>> "For the user != RO cases, I think that potentially having a way to
>>>>> signal those two items separately in the request and response could be
>>>>> useful. Right now all the user/subject stuff is about identifying “the user
>>>>> that’s currently here at the client instance”, in a variety of forms that
>>>>> the client instance and AS can negotiate. If the client or AS has some
>>>>> other notion about who the RO is and how that could be separate from the
>>>>> current user, we could provide a way to signal that like you’re proposing
>>>>> below. In my mental model, there are going to be a lot of use cases where
>>>>> the “RO” isn’t known to the client at all, but rather to the AS and is
>>>>> based on what the client’s asking for. So I could identify the current user
>>>>> and ask for a specific medical record, and the AS realizes it has to go bug
>>>>> a particular doctor to approve things directly. This is instead of
>>>>> interacting with the current user and failing in an awkward way when the
>>>>> current user doesn’t have the rights to do things, but someone else would.
>>>>> But we’d want the system to be able to detect if the current user is the
>>>>> doctor, so we can just interact with them directly. Does that all track?"
>>>>>
>>>>> I agree with the general idea. In the end, that's the AS's
>>>>> responsibility (and also a big part of its value as a policy engine).
>>>>>
>>>>> Even in the cases - as I suggested - where the client would be able to
>>>>> signal what it knows (or thinks it knows) about the subject, the AS still
>>>>> needs to validate what it can. The client could be an attacker lying to the
>>>>> AS. Or there could be an unintended bug.
>>>>>
>>>>> The client still seems like a straightforward source to gather
>>>>> optional/declarative hints. Which is what request.user is already doing in
>>>>> spirit. In many cases, the AS should go a step further. Validate
>>>>> cryptographic statements from a more reputable issuer, whatever helps.
>>>>>
>>>>> Contacts might be one of the possibilities. I'm not suggesting
>>>>> interact/fail scenarii at all, which I see as anti-ergonomic (composability
>>>>> with timeouts and fallback is the answer to that). The failure I was
>>>>> considering is only for async calls explicitly requested by the client
>>>>> (which is considered in sequence 1.4.3, and not coming from me), there's
>>>>> obviously no way to ensure a remote RO would actually respond when the
>>>>> client expects it. If that sequence is considered, realistic failure modes
>>>>> should be anticipated and dealt with internally (just like any distributed
>>>>> program would do), is all I'm saying. And so from the outside, there's no
>>>>> interact/fail.
>>>>> That's the same as in real life: when booking a business trip, an
>>>>> employee could either follow the generic rule (2nd class train ticket) or
>>>>> reach out to his manager, explaining that it's a long trip and that 1st
>>>>> class would be better. The employee knows the manager might not instantly
>>>>> respond, and knows that the absence of an answer means he'll have to go for
>>>>> the 2nd class.
>>>>>
>>>>> There will be cases when the client doesn't know the RO. I'm not sure
>>>>> if that's a majority of cases, but it will definitely happen. It could
>>>>> happen when you interact with an organization or a team and have no idea
>>>>> who's responsible or what delegations are in place (some of those cases
>>>>> have been described by Adrian for instance).
>>>>> There could also be cases where the ownership could be distributed (an
>>>>> example was provided when considering remote ROs). Again in real life, it's
>>>>> not unusual for a decision to fallback on a deputy when the main decision
>>>>> maker is unavailable. Or there could be an open governance even, but maybe
>>>>> that's one step too far.
>>>>>
>>>>> Of course, if the AS has internal knowledge or other ways to get the
>>>>> information it should use it. Remains to be seen how we can specify that
>>>>> (cf issue #49 on should/must). The example with doctor/patient is fine if
>>>>> hardcoded, but it becomes a problem when we fail to understand the real
>>>>> relationships in environments of various sensitive nature. How the AS
>>>>> identifies that a specific record requires approval from Doctor Bob might
>>>>> be context dependent (sometimes it could be a nurse, a team of doctors,
>>>>> another medical organization, etc.). Maybe you could have various levels of
>>>>> authorizations (extreme example: military style classifications), so that
>>>>> it might even be impossible to tell who can be contacted.
>>>>>
>>>>> That's also why I was suggesting assertions could go beyond
>>>>> authentication events, and include cryptographic assertions for
>>>>> authorization purposes. Maybe we can even imagine a risk based approach, as
>>>>> in some cases we won't know for sure.
>>>>>
>>>>> The difficulty will be to be sufficiently generic but simple enough.
>>>>> Maybe we can rule out some cases. Maybe remote async contacts are out of
>>>>> scope, because we only want instantaneous authorizations. Most of those
>>>>> cases are way beyond what OAuth2 does. I don't know. But what's certain is
>>>>> that the WG should decide what support for cases where end-user != RO it
>>>>> intends to provide. My discussion was just a very small Chesterston's Fence
>>>>> contribution, even if that seems to have surprised.
>>>>>
>>>>> Fabien
>>>>>
>>>>>
>>>>> On Wed, Mar 10, 2021 at 8:18 PM Justin Richer <jricher@mit.edu> wrote:
>>>>>
>>>>>> Hi Fabien,
>>>>>>
>>>>>> First, thanks for doing the heavy lift of writing this topic up. Of
>>>>>> these options, I would strongly prefer option (1). The difference between
>>>>>> assertions and identifiers is that an assertion is a fully packaged set of
>>>>>> attributes, one of which can be an identifier. They are, generally
>>>>>> speaking, cryptographically protected bundles. They’re designed to carry a
>>>>>> bunch of different information about a user and the authentication event in
>>>>>> a form that’s independently verifiable and auditable. SAML assertions (XML
>>>>>> document) and ID Tokens (signed JWTs) are the most common ones we see
>>>>>> today, but other formats exist and will keep being invented.
>>>>>>
>>>>>> An identifier is a different kind of creature. It is a single
>>>>>> statement that identifies the party in question in the context of the party
>>>>>> doing the identification. It’s this full context that the receiver of the
>>>>>> identifier needs to interpret it in. When using a federated identity
>>>>>> protocol, each RP is going to have :some: kind of local user information
>>>>>> store that they’re going to tie into, some field in a database they’ll key
>>>>>> off of. It’s just never going to be the case that all RPs will be able to
>>>>>> use server-provided opaque identifiers for all cases. Account recovery and
>>>>>> binding is one such use case where a user-facing identifier like an email
>>>>>> address makes a LOT of sense, for one small example. This is an array in
>>>>>> the request and response precisely because a user could be known by several
>>>>>> different identifiers to a party, and an RP will have a better idea about
>>>>>> what kinds of things it wants to correlate against, and it’s up to the AS
>>>>>> to provide that mapping. I think that if we don’t define a way to describe
>>>>>> the format, the “as_id” field is going to get structure back-patched onto
>>>>>> it like is being proposed here:
>>>>>>
>>>>>> https://mattrglobal.github.io/oidc-portable-identities/
>>>>>>
>>>>>> I’m personally not a fan of that approach as it mixes the data
>>>>>> layering too much, and you end up making guesses about whether a field is
>>>>>> meaningful or a pointer. I think GNAP will be much better served by using a
>>>>>> data structure for this from the start. DIDs should be another “format” of
>>>>>> the subject identifier. I don’t think GNAP should define this format, and
>>>>>> I’ve dropped a note to the SECEVENT mailing list asking about adding DIDs
>>>>>> to the subject identifiers draft before it gets published. DIDs are not
>>>>>> assertions, even in the cases where they point to fully functional DID
>>>>>> documents with user information in them. (And for what it’s worth, I think
>>>>>> the OIDC world should also use the SECEVENT draft inside ID Tokens to solve
>>>>>> the use case of the draft above).
>>>>>>
>>>>>> For the user != RO cases, I think that potentially having a way to
>>>>>> signal those two items separately in the request and response could be
>>>>>> useful. Right now all the user/subject stuff is about identifying “the user
>>>>>> that’s currently here at the client instance”, in a variety of forms that
>>>>>> the client instance and AS can negotiate. If the client or AS has some
>>>>>> other notion about who the RO is and how that could be separate from the
>>>>>> current user, we could provide a way to signal that like you’re proposing
>>>>>> below. In my mental model, there are going to be a lot of use cases where
>>>>>> the “RO” isn’t known to the client at all, but rather to the AS and is
>>>>>> based on what the client’s asking for. So I could identify the current user
>>>>>> and ask for a specific medical record, and the AS realizes it has to go bug
>>>>>> a particular doctor to approve things directly. This is instead of
>>>>>> interacting with the current user and failing in an awkward way when the
>>>>>> current user doesn’t have the rights to do things, but someone else would.
>>>>>> But we’d want the system to be able to detect if the current user is the
>>>>>> doctor, so we can just interact with them directly. Does that all track?
>>>>>>
>>>>>>  — Justin
>>>>>>
>>>>>> On Mar 10, 2021, at 4:10 AM, Fabien Imbault <fabien.imbault@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> Notice the question mark in the title. Not to be considered as an
>>>>>> editor's comment.
>>>>>> This thread intends to provide a detailed comment on the
>>>>>> interesting feedback by Kristina: "I would catch up on the thread to
>>>>>> understand why DIDs are thought to be treated as assertions".
>>>>>> In the chat, I answered: "Happy to get the discussion on DIDs.
>>>>>> Actually, could be either or, depending on what we intend to do." Let me
>>>>>> expand a bit on that, to make it understandable (didn't have the time
>>>>>> during the meeting, unfortunately).
>>>>>>
>>>>>> This relates to the items described on slides 20 and 34, which I'll
>>>>>> explain further. I'll highlight as transparently as possible what I think
>>>>>> would be the benefits and downsides of each. Both are probably viable
>>>>>> options, but they correspond to different scopes and objectives. I'll spend
>>>>>> a bit more time on option 2, since it is a different approach compared to
>>>>>> the current draft.
>>>>>>
>>>>>> *1. The first possibility is to use SECEVENT throughout. *
>>>>>> In that case, DIDs should be a part of sub_ids (in the core or in the
>>>>>> extension registry, depending on what Annabelle's WG decides). More
>>>>>> generally, the WG would have to decide which additional sub_ids it needs
>>>>>> (as per Yaron's comment).
>>>>>>
>>>>>> That's obviously the closest to what is described in draft-04. It
>>>>>> allows a communication of subject information between the client and the
>>>>>> AS, by using global identifiers (mail, phone, etc.), or using a local
>>>>>> opaque reference - i.e. governed by the AS (that's probably what we
>>>>>> would put in the examples, unless someone has a better idea - cf issues #16
>>>>>> and #42).
>>>>>>
>>>>>> Assertions relate for instance to the proof of presence of the RO.
>>>>>> The current draft-04 therefore plans for id_tokens and saml2, maybe there
>>>>>> could be other needs later (extension registry).
>>>>>>
>>>>>> - Benefits: identifiers are a key component of GNAP, which makes
>>>>>> integration easier. Possibly one could choose to use DIDs throughout.
>>>>>> - Downsides: email/phone identifiers will probably be used throughout
>>>>>> by most devs (since that's correlation information they have in their user
>>>>>> DB). Which means we should limit what assertions contain, to avoid doing
>>>>>> links between weak global identifiers and hopefully stronger assertions.
>>>>>> That's not really a problem if it's limited to authentication events mostly
>>>>>> (in that perspective, samlv2 could make sense in the core). An assertion is
>>>>>> probably a single value then (not an array).
>>>>>>
>>>>>> Option 1 can be summarized as:
>>>>>>
>>>>>> "subject": {
>>>>>>    "sub_ids": { }, // request and response (SECEVENT -> including
>>>>>> DID possibly)
>>>>>>    "assertions": [ ],               // request and response (id_token
>>>>>> or samlv2)
>>>>>> }
>>>>>> ("hints" do not exist currently, but are partially covered separately
>>>>>> via "request.user" / the relevance of "principal", discussed in the slide,
>>>>>> is a question mark too - which is a different discussion on end-user != RO).
>>>>>>
>>>>>>
>>>>>> *2. An alternate possibility is to use SECEVENT only as input/hint*
>>>>>> In that case, DIDs should be a part of assertions (which have a
>>>>>> different meaning compared to option 1).
>>>>>>
>>>>>> The AS only returns an local opaque reference as_ref (while in option
>>>>>> 1, it was only one of many possibilities). Its only job is to help the
>>>>>> client differentiate the response subject. The AS policy might further
>>>>>> define the scope of that reference, as suggested in
>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/210,
>>>>>> although I personally viewed that by default as (2) "as_id" an identifier
>>>>>> locally unique to that AS for all the RSs.
>>>>>>
>>>>>> SECEVENTS are still useful as an input, that's what I presented in
>>>>>> request.hints.self.sub_ids (but it's the responsibility of the AS to match
>>>>>> it with its own reference system - from instance from the email to AS's
>>>>>> local record XUT2MFM1XBIKJKSDU8Q). Note: since the slides, a new
>>>>>> draft-ietf-secevent-subject-identifiers-07 has been published. Notably this
>>>>>> includes an opaque identifier, which the client can use to pass the as_ref
>>>>>> hint to the AS. Thus we wouldn't need any further addition to
>>>>>> SECEVENT, although hints would benefit from further additions (like DIDs
>>>>>> for instance). Notice also that subject_types_supported becomes less
>>>>>> important, because in the worst case scenario, it's simply a hint that
>>>>>> wouldn't be understood and therefore taken into account by the AS.
>>>>>>
>>>>>> The assertions array has a more important role than in option 1 (with
>>>>>> the explicit aim of separating between client hints and validated info
>>>>>> asserted by the AS). It serves as a generic/extendible mapping structure,
>>>>>> e.g. "the AS asserts that opaque reference XUT2MFM1XBIKJKSDU8Q is
>>>>>> matching with these (more or less verifiable) statements." The name
>>>>>> assertion therefore corresponds to the responsibility of the AS in
>>>>>> delivering those statements (cf should/must, issue #49). Some of these
>>>>>> statements relate to identity or auth events (ex: DID, id_token), some
>>>>>> might directly be useful for authorization decisions (like ZKP example in
>>>>>> the parental control example). Possibly some of these validated assertions
>>>>>> could be reused in next interactions.
>>>>>>
>>>>>> Another question that popped-up is the scope of sub_ids. Should they
>>>>>> be about the same user? (I think so). In the case of remote ROs especially,
>>>>>> it might be important that DID be considered as an assertion (about someone
>>>>>> else's) and not as sub_ids, because the AS needs to be careful about who
>>>>>> the client wants to reach (avoid spam, etc.). This is consistent with the
>>>>>> rest of discussion on what to do when end-user != RO, although using
>>>>>> DIDComm might seem a bit early (the paint is very fresh).
>>>>>>
>>>>>> Option 2 was summarized as:
>>>>>>
>>>>>> // (suggestion only, not as an editor)
>>>>>> "subject": {
>>>>>>    "as_ref": { // response only (wouldn’t require SECEVENT)
>>>>>> “as”: “https://ex1.as.com”,
>>>>>> “ref”: “XUT2MFM1XBIKJKSDU8QM”
>>>>>>    },
>>>>>>    "assertions": [ ],               // request and response
>>>>>> (id_token/jwkthumb/DID/VC/etc. -> whatever info can be validated by the AS)
>>>>>>
>>>>>>    "hints": {                       // request only (optional)
>>>>>>       "self": { // replaces request.user (support SECEVENT here)
>>>>>>    “sub_ids”: { }, // SECEVENT (including opaque in draft-07 - that
>>>>>> could contain the ref)
>>>>>>    “assertions”: [ ] // see examples: VC on DOB or ZKP on age (wider
>>>>>> scope, possibly through extensions)
>>>>>> },
>>>>>>       "principal": { // new proposal presented at IETF110 (just an
>>>>>> idea)
>>>>>>   “automated”: true, // rule engine
>>>>>>   “async”: { } // remote ROs
>>>>>> }
>>>>>>    }
>>>>>> }
>>>>>>
>>>>>> - Benefits: as_ref is self supporting (no strong coupling with
>>>>>> SECEVENT), but can still take SECEVENT as an input hint for the AS. It
>>>>>> avoids the risk of making an official association between a weak global
>>>>>> identifier (e.g. email, used elsewhere) and hopefully stronger local
>>>>>> assertions. GNAP would be fully agnostic to whatever identity system is
>>>>>> used, only facilitating interoperability through assertions (second only in
>>>>>> importance compared to the AS opaque reference). Some assertions (possibly
>>>>>> extensions) could also be useful for the AS decision (e.g. VC or ZKP).
>>>>>> - Downsides: opaqueness of as_ref is a feature, not a bug. The opaque
>>>>>> reference is fully managed by the AS, therefore not inherently portable (cf
>>>>>> portability discussions in OIDC currently). There's no explicit binding to
>>>>>> an official identity, only a contextual mapping to AS validated assertions.
>>>>>> It makes it more difficult to match the identifiers from one AS to another
>>>>>> or to correlate with the client user DB (still possible via assertions, if
>>>>>> the AS allows it). Assertions are much more generic (possibly via
>>>>>> extensions), but might require a more advanced mechanism to
>>>>>> request/response only the most relevant information (which makes the AS
>>>>>> policy critical here).
>>>>>>
>>>>>> I hope that clarifies the reasoning for both options. Again I'm not
>>>>>> saying option 2 is better, just saying the trade-offs are different (+
>>>>>> knowing that we need to keep it simple).
>>>>>> - option 1 puts more in sub_ids and less in assertions
>>>>>> - option 2 puts less in the reference and more in assertions
>>>>>> All of this is open to discussion. More generally speaking, on every
>>>>>> part in orange and question mark (?) I would love your ideas and
>>>>>> criticisms. What I intended as an editor is only to highlight where the WG
>>>>>> has important choices to make, before we can make the related PRs.
>>>>>>
>>>>>> A further side comment: IETF EAT RATS was suggested for assertions,
>>>>>> but relates more to the client attestations. It was added as a comment in
>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/44, which
>>>>>> is a distinct topic we'll work on.
>>>>>>
>>>>>> Fabien (editor's hat off)
>>>>>>
>>>>>> --
>>>>>> TXAuth mailing list
>>>>>> TXAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>>>
>>>>>>
>>>>>> --
>>>> TXAuth mailing list
>>>> TXAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>
>>>
>>> This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.
>>>
>>> --
>> TXAuth mailing list
>> TXAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/txauth
>>
>