Subject: [GNAP] DID as sub_id or assertion?

From: Fabien Imbault <[email-masked]>
Date: Wed, 10 Mar 2021 10:10:52 +0100

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)

---

From: Tobias Looker <[email-masked]>
Date: Thu, 11 Mar 2021 06:30:32 +1300

Hi All,

Just my two cents, I don't understand why a DID on its own would be
regarded as an assertion about the subject. A DID is just an identifier
like any other, the fact the identifier is also resolvable to cryptographic
material like public keys that *can *be used to validate cryptographic
assertions does not make the DID itself an assertion.

On first glance of your proposals Fabien I like the simplicity of option 1,
option 2 feels too abstracted.

Thanks,
 <https://mattr.global>
*Tobias Looker*
Mattr
+64 (0) 27 378 0461
[email-masked]
 <https://mattr.global> 
<https://www.linkedin.com/company/mattrglobal> 
<https://twitter.com/mattrglobal> 
<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 Wed, Mar 10, 2021 at 10:11 PM Fabien Imbault <[email-masked]>
wrote:

> 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.
>
> 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
> AS asserts that opaque reference XUT2MFM1XBIKJKSDU8Q is matching with
> these (more or less verifiable) statements." The name assertion therefore
>    “assertions”: [ ] // see examples: VC on DOB or ZKP on age (wider
> scope, possibly through extensions)
>
> },
>
> --
> TXAuth mailing list
> [email-masked]
> 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.

---

From: Fabien Imbault <[email-masked]>
Date: Wed, 10 Mar 2021 18:48:19 +0100

Thanks for the feedback, although I'm not sure what you mean by too
abstract.
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). Or said otherwise, it is the mapping between as_ref and
the DID (for that specific case).

On Wed, Mar 10, 2021 at 6:30 PM Tobias Looker <[email-masked]>
wrote:

> On first glance of your proposals Fabien I like the simplicity of option
> 1, option 2 feels too abstracted.
>
> Thanks,
>  <https://mattr.global>
> *Tobias Looker*
> Mattr
> +64 (0) 27 378 0461
>> Notice the question mark in the title. Not to be considered as an
>> editor'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
>> 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
>>    “sub_ids”: { }, // SECEVENT (including opaque in draft-07 - that
>> could contain the ref)
>>
>> 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).
> 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.
>
>

---

From: Fabien Imbault <[email-masked]>
Date: Wed, 10 Mar 2021 19:21:10 +0100

Hi there,

A complementary set of questions for option 1 (SECEVENT):

- are you happy with the current list of subject identifiers? (i.e.
account/email/phone/iss_sub/aliases/opaque)
- what else would you need (in the context of GNAP, please indicate if
important or nice to have)?
- do you agree with having opaque examples in the text?

If needed, you can have a look at
https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers-07

Thanks.

Fabien

On Wed, Mar 10, 2021 at 6:48 PM Fabien Imbault <[email-masked]>
wrote:

>> This communication, including any attachments, is confidential. If you
>> are not the intended recipient, you should not read it - please contact me
>>> ("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).
>>>
>>>
>>>
>>> In that case, DIDs should be a part of assertions (which have a
>>> different meaning compared to option 1).
>>>
>>> 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.
>>>
>>> - 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).
>>> 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.
>>>
>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/44, which is
>>> a distinct topic we'll work on.
>>>

---

From: Justin Richer <[email-masked]>
Date: Wed, 10 Mar 2021 14:18:13 -0500

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/ <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 <[email-masked]> 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).   
> 
>    "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 <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). 
> 
> “as”: “https://ex1.as.com <https://ex1.as.com/>”,		
>    "assertions": [ ],                   // request and response (id_token/jwkthumb/DID/VC/etc. -> whatever info can be validated by the AS)
> 
>    “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)  
> },                  
> - 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).
> 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 <https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/44>, which is a distinct topic we'll work on.
>

---

From: Fabien Imbault <[email-masked]>
Date: Wed, 10 Mar 2021 21:19:42 +0100

Thanks Justin.

It's good to clarify what we mean by assertion. I used a more mundane
meaning.

I dislike email/phone as security disasters waiting to happen. I get that
they are practical.

I think I have what I need to write the PRs based on sub_ids (based on the
current draft-07).

Fabien

Le mer. 10 mars 2021 à 20:18, Justin Richer <[email-masked]> a écrit :

> 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
>

---

From: Tobias Looker <[email-masked]>
Date: Thu, 11 Mar 2021 10:02:21 +1300

abstract.

Apologies what I mean by that was I feel like Option 2 would expose too
much complexity to clients that would be required to construct a request to
the AS. Option 1 IMO strikes a better balance by still offering the
required flexibility but keeping things relatively simple.

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).

Thanks,
 <https://mattr.global>
*Tobias Looker*
Mattr
+64 (0) 27 378 0461

---

From: Justin Richer <[email-masked]>
Date: Wed, 10 Mar 2021 16:14:47 -0500

> 
> > 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

---

From: Fabien Imbault <[email-masked]>
Date: Wed, 10 Mar 2021 23:57:42 +0100

Hi Tobias,

Option 2's pros and cons are the consequence of solely relying only on an
opaque identifier managed by the AS, independantly from external
identifiers.

That's an additional level of indirection, not unlike how indexes are
usually managed in a database. But there's obviously the additional
complexity of making a just in time translation into a practical identifier
(like email for account recovery, as discussed by Justin).

"Assertions" should be what the AS (possibly with the assistance of other
parties) can confidently say about the subject.

Thanks for the great feedback, as well as Justin's. Since the slides were
written, SECEVENT draft-07 already offers new possibilities which is good
news.

Fabien

Le mer. 10 mars 2021 à 22:02, Tobias Looker <[email-masked]> a
écrit :

>> I think I have what I need to write the PRs based on sub_ids (based on
>> the current draft-07).
>>
>> 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
>>> 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
>>>

---

From: Fabien Imbault <[email-masked]>
Date: Thu, 11 Mar 2021 11:44:20 +0100

Hi Justin,

I think that's interesting:
"For the user != RO cases, I think that potentially having a way to signal
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

---

From: Denis <[email-masked]>
Date: Thu, 11 Mar 2021 19:50:34 +0100

Hi Fabien,

Thank you for launching the discussion.

SECEVENT draft-07 does not really offer new possibilities over draft-06. 
The major change is simply  in the syntax naming.

The response to your question is not limited to an exclusive choice 
between option 1 and option 2. :-)

The definition of a subject identifier in draft-07 is :

*3.Subject Identifiers *

*A Subject Identifier is a JSON [RFC7159] object whose contents may 
beused to identify a subject within some context.An Identifier Formatis 
a named definition of a set of information that may be used toidentify a 
subject, and the rules for encoding that information as aSubject 
Identifier; they define the syntax and semantics of Subject Identifiers.*

With such a definition is it possible to request some _/types /_of 
subject identifiers to be placed into an access token,
to place subjects identifiers (with their values) into an access token 
and for a RS to compare these subjects identifiers
(with their values) against validation rules enacted by a RO acting as 
an ADF (Access Decision Function) which also use
the same subjects identifiers (with their values).

A DID is a persistent global unique identifier.

In issue #210  ("sub_id" claims #210) I already proposed the following 
examples for globally unique identifiers (gu_id) :

    (1) For a globally unique identifier:

    "sub_id": {
    "format": "gu_id",
    "gu_id": " email",
    "email: "[email-masked]",
    }

    or

    "sub_id": {
    "format": "gu_id",
    "gu_id": "ssn",
    "ssn": {
    "cn": "250"
    "value": "160087404506527",
    },
    }

In order to address DIDs, I would simply add the following example:

    "sub_id": {
    "format": "gu_id",
    "gu_id": " did",
    "did: "did:/DID:Method:DID Method Specific String/",
    }

"sub_ids" claims are much better when compared to "sub" claims.

The definition of Subject Identifier in the draft-07 (section 3) is :

        A Subject Identifier is a JSON [RFC7159] object whose contents
    may be
        used to identify a subject /within some context/.

However, page 2 of the draft-07 states:

        As described in Section 1.2 of SET [RFC8417], subjects /related to//
    //   security events/ may take a variety of forms, including but not
        limited to a JWT [RFC7519] principal, an IP address, a URL, etc.

RFC 8417 (Security Event Token (SET)) states in its abstract:

    Abstract

        This specification defines the /Security Event Token (SET) data//
    //   structure/.  A SET describes statements of fact from the
    perspective
        of an issuer about a subject.  These statements of fact represent an
        event that occurred directly to or about a security subject, for
        example, a statement about the issuance or revocation of a token on
        behalf of a subject.  This specification is intended to enable
        representing security- and identity-related events.  A SET is a JSON
        Web Token (JWT), which can be optionally signed and/or encrypted.
        SETs can be distributed via protocols such as HTTP.

    There is a need to be able to use subject identifiers that will not
    necessarily be used in
    a Security Event Token (SET) data structure.

These Subject Identifiers might still be used in a Security Event Token 
(SET) data structure, /but not necessarilly/.

  * When supporting RBAC (Role Based Access Control), it would be nice
    to define "sub_ids" able to support roles.
  * When supporting ABAC (Attribute Bases Access Control), it would be
    nice to define "sub_ids" able to support
    group memberships with two flavours of them : (a) hierarchical
    groups and (b) functional groups;

The current title of the draft is: "Subject Identifiers for Security 
Event Tokens" .
More appropriate titles would be:

    Subject Identifiers for Security Event Tokens /a//nd other purposes/

or simply

    Subject Identifiers

The first sentence of the abstract should also be slightly modified.

Denis

> Hi Tobias,
>
> Option 2's pros and cons are the consequence of solely relying only on 
> an opaque identifier managed by the AS, independantly from external 
> identifiers.
>
> complexity of making a just in time translation into a practical 
> identifier (like email for account recovery, as discussed by Justin).
>
> "Assertions" should be what the AS (possibly with the assistance of 
> other parties) can confidently say about the subject.
>
> Thanks for the great feedback, as well as Justin's. Since the slides 
> were written, SECEVENT draft-07 already offers new possibilities which 
> is good news.
>
> Fabien
>
> Le mer. 10 mars 2021 à 22:02, Tobias Looker 
> <[email-masked]> a écrit :
>
>     > Thanks for the feedback, although I'm not sure what you mean by
>     too abstract.
>
>     Apologies what I mean by that was I feel like Option 2 would
>     expose too much complexity to clients that would be required to
>     construct a request to the AS. Option 1 IMO strikes a better
>     balance by still offering the required flexibility but keeping
>     things relatively simple.
>
>     > 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).
>
>     Thanks,
>     Mattr website <https://mattr.global> 		
>     *Tobias Looker*
>     Mattr
>     +64 (0) 27 378 0461
>     [email-masked] <mailto:[email-masked]>
>     Mattr website <https://mattr.global> 	Mattr on LinkedIn
>     <https://www.linkedin.com/company/mattrglobal> 	Mattr on Twitter
>     <https://twitter.com/mattrglobal> 	Mattr on Github
>     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 Thu, Mar 11, 2021 at 9:20 AM Fabien Imbault
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         Thanks Justin.
>
>         It's good to clarify what we mean by assertion. I used a more
>         mundane meaning.
>
>         I dislike email/phone as security disasters waiting to happen.
>         I get that they are practical.
>
>         I think I have what I need to write the PRs based on sub_ids
>         (based on the current draft-07).
>
>         Fabien
>
>         Le mer. 10 mars 2021 à 20:18, Justin Richer <[email-masked]
>         <mailto:[email-masked]>> a écrit :
>
>             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
>>             <[email-masked]
>>             <mailto:[email-masked]>> wrote:
>>
>>             Hello,
>>
>>             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.
>>
>>             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).
>>
>>                "sub_ids": { },// request and response (SECEVENT ->
>>             including DID possibly)
>>             ("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).
>>
>>
>>             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
>>             <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).
>>
>>                "assertions": [ ],               // request and
>>             response (id_token/jwkthumb/DID/VC/etc. -> whatever info
>>             can be validated by the AS)
>>
>>                “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).
>>             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
>>             <https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/44>,
>>             which is a distinct topic we'll work on.
>>
>>             [email-masked] <mailto:[email-masked]>
>>             <https://www.ietf.org/mailman/listinfo/txauth>
>
>
>         -- 
>         TXAuth mailing list
>         [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/txauth>
>
>

---

From: Fabien Imbault <[email-masked]>
Date: Thu, 11 Mar 2021 19:56:31 +0100

Hi Denis,

There's one big change in draft 07 : opaque identifiers.
That's basically what we discussed in
https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/51

Fabien

On Thu, Mar 11, 2021 at 7:50 PM Denis <[email-masked]> wrote:

> *3.  Subject Identifiers
> *
> *   A Subject Identifier is a JSON [RFC7159] object whose contents may be
>    used to identify a subject within some context.  An Identifier Format
>    is a named definition of a set of information that may be used to
>    identify a subject, and the rules for encoding that information as a
>    Subject Identifier; they define the syntax and semantics of Subject
>    Identifiers.*
>
> With such a definition is it possible to request some *types *of subject
> identifiers to be placed into an access token,
> to place subjects identifiers (with their values) into an access token and
> for a RS to compare these subjects identifiers
> (with their values) against validation rules enacted by a RO acting as an
> ADF (Access Decision Function) which also use
>        "email: "[email-masked]" <[email-masked]>,
>      }
>
> or
>
> "sub_id": {
>        "format": "gu_id",
>        "gu_id": "ssn",
>        "ssn": {
>                     "cn": "250"
>        "did: "did:*DID:Method:DID Method Specific String*",
>      }
>
>    A Subject Identifier is a JSON [RFC7159] object whose contents may be
>    used to identify a subject *within some context*.
>
>    As described in Section 1.2 of SET [RFC8417], subjects *related to*
> *   security events* may take a variety of forms, including but not
>    This specification defines the *Security Event Token (SET) data*
> *   structure*.  A SET describes statements of fact from the perspective
> (SET) data structure, *but not necessarilly*.
>
>    - When supporting RBAC (Role Based Access Control), it would be nice
>    - When supporting ABAC (Attribute Bases Access Control), it would be
>    group memberships with two flavours of them : (a) hierarchical groups
>    and (b) functional groups;
>
> The current title of the draft is: "Subject Identifiers for Security Event
> Tokens" .
> Subject Identifiers for Security Event Tokens *a**nd other purposes*
>
> or simply
>
> Subject Identifiers
>
> Le mer. 10 mars 2021 à 22:02, Tobias Looker <[email-masked]>
>>> I dislike email/phone as security disasters waiting to happen. I get
>>> that they are practical.
>>>
>>>> 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).
>>>>
>>>> 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).
>>>>
>>>> - Downsides: email/phone identifiers will probably be used throughout
>>>> by most devs (since that's correlation information they have in their user
>>>> 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.
>>>>

---

From: Justin Richer <[email-masked]>
Date: Thu, 11 Mar 2021 14:58:26 -0500

Denis,

Many of your comments here would be best addressed to the SECEVENT working group as feedback on the subject identifiers draft. There is new text in -07 that helps establish this as useful outside of SET/JWT, and I would guess the author would be amenable to clarifying that further.

 — Justin

> On Mar 11, 2021, at 1:50 PM, Denis <[email-masked]> wrote:
> 
> Hi Fabien,
> 
> SECEVENT draft-07 does not really offer new possibilities over draft-06. The major change is simply  in the syntax naming.
> 
> The response to your question is not limited to an exclusive choice between option 1 and option 2. :-)
> 
> 3.  Subject Identifiers 
>    Identifiers.
> With such a definition is it possible to request some types of subject identifiers to be placed into an access token, 
> to place subjects identifiers (with their values) into an access token and for a RS to compare these subjects identifiers 
> (with their values) against validation rules enacted by a RO acting as an ADF (Access Decision Function) which also use
> In issue #210  ("sub_id" claims #210) I already proposed the following examples for globally unique identifiers (gu_id) :
>        "email: "[email-masked]" <mailto:[email-masked]>,
>      }
> 
> or
> 
> "sub_id": {
>        "format": "gu_id",
>        "gu_id": "ssn",
>        "ssn": { 
>                     "cn": "250"
>        "did: "did:DID:Method:DID Method Specific String",
>      }
>    used to identify a subject within some context.  
>    As described in Section 1.2 of SET [RFC8417], subjects related to
>    security events may take a variety of forms, including but not
>    This specification defines the Security Event Token (SET) data
>    structure.  A SET describes statements of fact from the perspective
> There is a need to be able to use subject identifiers that will not necessarily be used in
> These Subject Identifiers might still be used in a Security Event Token (SET) data structure, but not necessarilly.
> When supporting RBAC (Role Based Access Control), it would be nice to define "sub_ids" able to support roles.
> When supporting ABAC (Attribute Bases Access Control), it would be nice to define "sub_ids" able to support
> group memberships with two flavours of them : (a) hierarchical groups and (b) functional groups;
> The current title of the draft is: "Subject Identifiers for Security Event Tokens" .
> Subject Identifiers for Security Event Tokens and other purposes
> or simply
> Subject Identifiers
>> Option 2's pros and cons are the consequence of solely relying only on an opaque identifier managed by the AS, independantly from external identifiers. 
>> 
>> That's an additional level of indirection, not unlike how indexes are usually managed in a database. But there's obviously the additional complexity of making a just in time translation into a practical identifier (like email for account recovery, as discussed by Justin). 
>> 
>> "Assertions" should be what the AS (possibly with the assistance of other parties) can confidently say about the subject. 
>> 
>> Thanks for the great feedback, as well as Justin's. Since the slides were written, SECEVENT draft-07 already offers new possibilities which is good news. 
>> 
>> Fabien
>> 
>> Le mer. 10 mars 2021 à 22:02, Tobias Looker <[email-masked]> <mailto:[email-masked]> a écrit :
>> > Thanks for the feedback, although I'm not sure what you mean by too abstract.
>> 
>> Apologies what I mean by that was I feel like Option 2 would expose too much complexity to clients that would be required to construct a request to the AS. Option 1 IMO strikes a better balance by still offering the required flexibility but keeping things relatively simple.
>> 
>>  <https://mattr.global/>	 	
>> Tobias Looker
>>  <https://mattr.global/>	 <https://www.linkedin.com/company/mattrglobal>	 <https://twitter.com/mattrglobal>	 <https://github.com/mattrglobal>
>> On Thu, Mar 11, 2021 at 9:20 AM Fabien Imbault <[email-masked] <mailto:[email-masked]>> wrote:
>> Thanks Justin.
>> 
>> It's good to clarify what we mean by assertion. I used a more mundane meaning. 
>> 
>> I dislike email/phone as security disasters waiting to happen. I get that they are practical. 
>> 
>> I think I have what I need to write the PRs based on sub_ids (based on the current draft-07). 
>> 
>> Fabien 
>> 
>> Le mer. 10 mars 2021 à 20:18, Justin Richer <[email-masked] <mailto:[email-masked]>> a écrit :
>> Hi Fabien,
>> 
>>> On Mar 10, 2021, at 4:10 AM, Fabien Imbault <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hello,
>>> 
>>> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
>> 
>> 
>> -- 
>> TXAuth mailing list
>> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
>>

---

From: Fabien Imbault <[email-masked]>
Date: Fri, 12 Mar 2021 08:16:18 +0100

+1 for that.

On Thu, Mar 11, 2021 at 8:58 PM Justin Richer <[email-masked]> wrote:

> Denis,
>
> Many of your comments here would be best addressed to the SECEVENT working
> group as feedback on the subject identifiers draft. There is new text in
> -07 that helps establish this as useful outside of SET/JWT, and I would
> guess the author would be amenable to clarifying that further.
>
>  — Justin
>

---

From: Fabien Imbault <[email-masked]>
Date: Sat, 13 Mar 2021 09:26:19 +0100

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 <[email-masked]> a

---

From: Tobias Looker <[email-masked]>
Date: Wed, 17 Mar 2021 13:01:09 +1300

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,
 <https://mattr.global>
*Tobias Looker*
Mattr
+64 (0) 27 378 0461

On Sat, Mar 13, 2021 at 9:26 PM Fabien Imbault <[email-masked]>
wrote:

> 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
>
>> "For the user != RO cases, I think that potentially having a way to
>> doctor, so we can just interact with them directly. Does that all track?"
>>
>> 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.
>>
>> 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

---

From: Fabien Imbault <[email-masked]>
Date: Wed, 17 Mar 2021 02:59:32 +0100

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 <[email-masked]> a
écrit :

>> Le jeu. 11 mars 2021 à 11:44, Fabien Imbault <[email-masked]>
>> a écrit :
>>
>>> Hi Justin,
>>>
>>> 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).
>>>

---

From: Adrian Gropper <[email-masked]>
Date: Tue, 16 Mar 2021 22:10:36 -0400

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 <[email-masked]>
wrote:

> Le mer. 17 mars 2021 à 01:01, Tobias Looker <[email-masked]>
> a écrit :
>
>> Hi,
>>
>>>> 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).
>>>>> 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:
>>>>>
>>>>> 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
>>>>> 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
>>>>> 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.
>>>>>

---

From: Fabien Imbault <[email-masked]>
Date: Wed, 17 Mar 2021 03:34:50 +0100

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 <[email-masked]> a
écrit :

>> 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.
>>
>> 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
>>
>>
>>>> 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
>>>>>> 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).
>>>>>>

---

From: Fabien Imbault <[email-masked]>
Date: Wed, 17 Mar 2021 03:51:27 +0100

Note also that there's issue 197 that discussed that very question.
https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/197

Le mer. 17 mars 2021 à 03:34, Fabien Imbault <[email-masked]> 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?
>>
>>>>  <https://mattr.global> [image: Mattr on
>>>> LinkedIn] <https://www.linkedin.com/company/mattrglobal> [image: Mattr
>>>> on Twitter] <https://twitter.com/mattrglobal> 
>>>> On Sat, Mar 13, 2021 at 9:26 PM Fabien Imbault <
>>>> [email-masked]> wrote:
>>>>
>>>>> Hi Justin,
>>>>>
>>>>>> 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.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>>> 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
>>>>>>> - 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).
>>>>>>>
>>>>>>> (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).
>>>>>>>
>>>>>>>
>>>>>>> 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
>>>>>>> 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
>>>>>>> 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.
>>>>>>>
>>>>>>> - 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).
>>>>>>>

---

From: Adrian Gropper <[email-masked]>
Date: Tue, 16 Mar 2021 23:04:40 -0400

Thanks, Fabien.

We need to be verrry careful about the shortcuts once we add user and
end-user to our spec. RO = subject (of the resource secured by a RS) is
clear and independent of any AS or clients. DIDs can be helpful for the
RO-RS relationship for authentication, encryption, and service endpoints.
Authentication can facilitate pseudonymity by default. Encryption, for
example, can allow mediated communications for privacy enhancement.

When we bring the request of an end-user into the picture, the DID can
apply to someone other than the RO / subject. The DID can secure claims
that had nothing to do with the RO-RS (as you point out in #197). Also, in
many cases, the subject DID known to the requesting party might be
different from the DID associated with the RO at the RS. This promotes
privacy through DIDs as same-domain identifiers but has to be dealt with at
the policy decision point where capabilities are filtered.

Another source of potential confusion comes from the way we use client.
DIDs are generally not associated with a client except to the extent the
client is a user-agent such as a mobile wallet or an online policy and
capabilities agent.

My suggestion is that we arrive at a set of consistent names soon and
present them early in the spec - in what is now Section 1.2 - and avoid
using any shortcuts in the rest of the spec. I would also suggest we
provide examples of the use of DIDs relative to the names we define in 1.2.

Adrian

On Tue, Mar 16, 2021 at 10:51 PM Fabien Imbault <[email-masked]>
wrote:

>>> On Tue, Mar 16, 2021 at 10:00 PM Fabien Imbault <
>>>> 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
>>>>> LinkedIn] <https://www.linkedin.com/company/mattrglobal> [image:
>>>>> Mattr on Twitter] <https://twitter.com/mattrglobal> [image: Mattr on
>>>>> Github] <https://github.com/mattrglobal>
>>>>>> Le jeu. 11 mars 2021 à 11:44, Fabien Imbault <
>>>>>> [email-masked]> a écrit :
>>>>>>
>>>>>>> Hi Justin,
>>>>>>>
>>>>>>> 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
>>>>>>>> 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).
>>>>>>>>
>>>>>>>>    “assertions”: [ ] // see examples: VC on DOB or ZKP on age
>>>>>>>> (wider scope, possibly through extensions)
>>>>>>>> },
>>>>>>>> All of this is open to discussion. More generally speaking, on
>>>>>>>> every part in orange and question mark (?) I would love your ideas and
>>>>>>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/44,

---

From: Fabien Imbault <[email-masked]>
Date: Wed, 17 Mar 2021 04:42:22 +0100

Noted. I agree with that goal.

Back to identifiers, even if we'd use DIDs, the scope is restricted to the
subject.

Fabien

Le mer. 17 mars 2021 à 04:04, Adrian Gropper <[email-masked]> a
écrit :

>> Le mer. 17 mars 2021 à 03:34, Fabien Imbault <[email-masked]>
>> a écrit :
>>
>>> Hi Adrian,
>>>
>>>>> 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.
>>>>>
>>>>> 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
>>>>>
>>>>>
>>>>>> 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
>>>>>> 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
>>>>>>>> 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
>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>> 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
>>>>>>>>> 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
>>>>>>>>> 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 (+
>>>>>>>>> assertions, but relates more to the client attestations. It was added as a
>>>>>>>>> comment in

---

From: Adrian Gropper <[email-masked]>
Date: Wed, 17 Mar 2021 00:48:07 -0400

What do you mean the scope is restricted to the subject? DIDs are valuable
for all end-users and things like did:web can help interop with RSs. A
client might not have a DID but it could have a VC as a certificate of
authenticity linked to some audit mechanism.

Adrian

On Tue, Mar 16, 2021 at 11:42 PM Fabien Imbault <[email-masked]>
wrote:

>>>> 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 <[email-masked]>
>>>> a écrit :
>>>>
>>>>>> Le mer. 17 mars 2021 à 01:01, Tobias Looker
>>>>>>> Mattr on Twitter] <https://twitter.com/mattrglobal> [image: Mattr
>>>>>>> on Github] <https://github.com/mattrglobal>
>>>>>>>>> "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
>>>>>>>>> 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
>>>>>>>>>> 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
>>>>>>>>>> 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).
>>>>>>>>>>
>>>>>>>>>> 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

---

From: Fabien Imbault <[email-masked]>
Date: Wed, 17 Mar 2021 06:20:33 +0100

Currently I mostly see DID as alternative subject identifier (again
hypothetically since not currently included in SECEVENT).

You're right that DIDs could serve other purposes too. Denis has also asked
an interesting question on whether sub_ids might be used within the access
tokens (issue #210).

I do see some value in supporting VCs for assertions. In my early attempts
to map that, it seems to be applicable to the client instance (like the
client posture, or even a VP for the display) or to the end-user
(request.user).

We need to keep in mind that a big part of that discussion also depends on
what the SECEVENT WG decides.

Fabien

Le mer. 17 mars 2021 à 05:48, Adrian Gropper <[email-masked]> a
écrit :

>> Back to identifiers, even if we'd use DIDs, the scope is restricted to
>> the subject.
>>
>> Fabien
>>
>>
>>> On Tue, Mar 16, 2021 at 10:51 PM Fabien Imbault <
>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>>> That's obviously the closest to what is described in draft-04.
>>>>>>>>>>> It allows a communication of subject information between the client and the

---

From: Tobias Looker <[email-masked]>
Date: Thu, 18 Mar 2021 09:23:45 +1300

+1 I think DIDs are an interesting option to allow the subject identifier
to belong to a domain that is not controlled by the AS unlocking the
possibility of the End-User being able to have their identity portable
between AS's (hence the name portable identities being used of recent).

> A client might not have a DID but it could have a VC as a certificate of

To me a VC would come under the assertions umbrella (that is to say a VC
could be one type of valid assertion). The client may possess or been
presented with a VC that it could include in its request to the AS as a way
to identify the subject and perhaps prove authentication and authorization.

Thanks,
 <https://mattr.global>
*Tobias Looker*
Mattr
+64 (0) 27 378 0461

On Wed, Mar 17, 2021 at 6:20 PM Fabien Imbault <[email-masked]>
wrote:

> You're right that DIDs could serve other purposes too. Denis has also
> asked an interesting question on whether sub_ids might be used within the
> access tokens (issue #210).
>
>> What do you mean the scope is restricted to the subject? DIDs are
>> valuable for all end-users and things like did:web can help interop with
>> RSs. A client might not have a DID but it could have a VC as a certificate
>> of authenticity linked to some audit mechanism.
>>
>> Adrian
>>
>>>>>>> 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?
>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>>>> First, thanks for doing the heavy lift of writing this topic
>>>>>>>>>>>> up. Of these options, I would strongly prefer option (1). The difference
>>>>>>>>>>>> - Benefits: identifiers are a key component of GNAP, which
>>>>>>>>>>>> makes integration easier. Possibly one could choose to use DIDs throughout.

---

From: Adrian Gropper <[email-masked]>
Date: Wed, 17 Mar 2021 16:55:31 -0400

On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker <[email-masked]>
wrote:

> <snip>

I do not assume that the client that interacts with the AS to make a
request and receive a token is the same as the client that will present the
token to the RS. In the US HIPAA use-case, for example, the root of trust
is a contract between the patient-subject and the doctor-requesting party
but the doctor workflow is expected to delegate the token to some other
end-user that may be using a totally different client such as an EHR.

Adrian

---

From: Justin Richer <[email-masked]>
Date: Wed, 17 Mar 2021 17:29:21 -0400

On Mar 17, 2021, at 4:55 PM, Adrian Gropper <[email-masked]> wrote:
> 
> On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker <[email-masked]> wrote:
> <snip>
> > A client might not have a DID but it could have a VC as a certificate of authenticity linked to some audit mechanism.
> 
> To me a VC would come under the assertions umbrella (that is to say a VC could be one type of valid assertion). The client may possess or been presented with a VC that it could include in its request to the AS as a way to identify the subject and perhaps prove authentication and authorization.
> 
> I do not assume that the client that interacts with the AS to make a request and receive a token is the same as the client that will present the token to the RS. In the US HIPAA use-case, for example, the root of trust is a contract between the patient-subject and the doctor-requesting party but the doctor workflow is expected to delegate the token to some other end-user that may be using a totally different client such as an EHR.
> 

If the client that gets the token is not same as the client that uses the token, that is a violation of core security principles as it allows for (and really designs for) impersonation by client software. I would have no reason to trust client software that would hand its credentials over to another piece of software, and in fact I shouldn’t trust it. 

I think you may be conflating several different kinds of parties under the “client” umbrella here, though. It’s entirely possible that one client might call an RS that in turn acts as a client for something else down stream. But each of those hops is different from the last.

 — Justin

---

From: Adrian Gropper <[email-masked]>
Date: Wed, 17 Mar 2021 19:18:44 -0400

I'm sure you're right. Our vague terminology around client and end-user
leads to my confusion. If GNAP is primarily about delegation then, of
course, we should avoid any incentives to impersonate or we're wasting our
time. This is partly why I'm trying to study up on capabilities and asking
for expert advice from folks like Alan Karp and Mark Miller (cc'd)

As best I can understand it, the RS has only two choices, it can:

   - store an attribute of the RO a [DID, email address, GNAP AS URL], or
   - hand the RO a capability as a sort-of promise and avoid making any
   entries in an ACL or equivalent.

When a token comes back to the RS, it will either be:

   - validated according to something associated with the stored RO
   attribute, or
   - signed by the RS itself.

Either way, trust in the client seems moot.

Adrian

On Wed, Mar 17, 2021 at 5:29 PM Justin Richer <[email-masked]> wrote:

>> > A client might not have a DID but it could have a VC as a certificate
> If the client that gets the token is not same as the client that uses the
> token, that is a violation of core security principles as it allows for
> (and really designs for) impersonation by client software. I would have no
> reason to trust client software that would hand its credentials over to
> another piece of software, and in fact I shouldn’t trust it.
>
> I think you may be conflating several different kinds of parties under the
> “client” umbrella here, though. It’s entirely possible that one client
> might call an RS that in turn acts as a client for something else down
> stream. But each of those hops is different from the last.
>
>  — Justin
>
>

---

From: Justin Richer <[email-masked]>
Date: Wed, 17 Mar 2021 19:36:31 -0400

I still think the RS doesn’t do these things, the AS does. The AS is the component of the “API Provider’ (in your use case model) that handles the authorizations. The RS just fulfills them. They are part of the same trust boundary.

 — Justin

> On Mar 17, 2021, at 7:18 PM, Adrian Gropper <[email-masked]> wrote:
> 
> I'm sure you're right. Our vague terminology around client and end-user leads to my confusion. If GNAP is primarily about delegation then, of course, we should avoid any incentives to impersonate or we're wasting our time. This is partly why I'm trying to study up on capabilities and asking for expert advice from folks like Alan Karp and Mark Miller (cc'd)
> 
> store an attribute of the RO a [DID, email address, GNAP AS URL], or
> hand the RO a capability as a sort-of promise and avoid making any entries in an ACL or equivalent.
> validated according to something associated with the stored RO attribute, or
> signed by the RS itself.
> On Wed, Mar 17, 2021 at 5:29 PM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> On Mar 17, 2021, at 4:55 PM, Adrian Gropper <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> On Wed, Mar 17, 2021 at 4:23 PM Tobias Looker <[email-masked] <mailto:[email-masked]>> wrote:
>> <snip>

---

From: Adrian Gropper <[email-masked]>
Date: Wed, 17 Mar 2021 19:56:33 -0400

That's the vagueness we're talking about. For me, the RS holds all the
cards and can choose whether to hold them or pass them to some other actor.
"Same trust boundary" just reinforces that mental model for me, it's a
technicality that splits one actor into two pieces. If the RS does this it
should be completely invisible to GNAP and I would call the whole thing RS
anyway.

The reason I advocate for GNAP in the SSI workgroups is exactly because SSI
does not depend on "trust boundary" - which to me is another name for
"federation".

So, on the protocols side, I propose, in both the SSI and GNAP groups, that
the AS be defined as the actor that has policies, requests, and
capabilities in order to emit tokens. If there's a reason to treat this
actor as a trust boundary around an RO + the user-agent or the RO + an AS,
then I'm happy to state that explicitly.

Adrian

On Wed, Mar 17, 2021 at 7:36 PM Justin Richer <[email-masked]> wrote:

> I still think the RS doesn’t do these things, the AS does. The AS is the
> component of the “API Provider’ (in your use case model) that handles the
> authorizations. The RS just fulfills them. They are part of the same trust
> boundary.
>
>  — Justin
>
>> I think you may be conflating several different kinds of parties under
>> the “client” umbrella here, though. It’s entirely possible that one client

---

From: Fabien Imbault <[email-masked]>
Date: Thu, 18 Mar 2021 03:19:50 +0100

Hi Adrian

I'm still confused why you're saying the terminology is vague.
I get the "power" neutrality is not to your liking, but RQ / user agent is
no better in my view.

Can you elaborate?

Fabien

Le jeu. 18 mars 2021 à 00:18, Adrian Gropper <[email-masked]> a

---

From: Adrian Gropper <[email-masked]>
Date: Wed, 17 Mar 2021 23:29:42 -0400

At various points in the lifecycle of the protected resource the client at
the resource server (RS) might be:

   - The RO (subject) user agent trading payment for a service promise
   - The RO user agent using the promise to access the protected resource
   - A delegate of the RO user agent using a different client

What's vague is where the GNAP AS enters the picture as described above.
How would you describe it?

Adrian

On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault <[email-masked]>
wrote:

>>>> To me a VC would come under the assertions umbrella (that is to say a
>>>> VC could be one type of valid assertion). The client may possess or been
>>> If the client that gets the token is not same as the client that uses
>>> the token, that is a violation of core security principles as it allows for

---

From: Fabien Imbault <[email-masked]>
Date: Thu, 18 Mar 2021 04:43:03 +0100

Thanks for that.

Trying to reframe it:
GNAP is defined as a delegation protocol so the main intent is related to a
delegate of the RO (i.e. the end user) that wishes to access the RO's
protected resources, through the client.

Fabien

Le jeu. 18 mars 2021 à 04:29, Adrian Gropper <[email-masked]> a
écrit :

>> I get the "power" neutrality is not to your liking, but RQ / user agent
>> is no better in my view.
>>
>> Can you elaborate?
>>
>> Fabien
>>
>>>>> > A client might not have a DID but it could have a VC as a
>>>>> certificate of authenticity linked to some audit mechanism.
>>>>>

---

From: Adrian Gropper <[email-masked]>
Date: Wed, 17 Mar 2021 23:54:02 -0400

Sure!

Is there an AS involved in the delegation? How and where in the
lifecycle of the protected resource?

Also your use of "the client" seems to imply that either there is only one
client or the client doesn't matter. Which is it?

Adrian

On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault <[email-masked]>
wrote:

> Thanks for that.
>
> Trying to reframe it:
> GNAP is defined as a delegation protocol so the main intent is related to
> a delegate of the RO (i.e. the end user) that wishes to access the RO's
>> At various points in the lifecycle of the protected resource the client
>> at the resource server (RS) might be:
>>
>>>>    - hand the RO a capability as a sort-of promise and avoid making
>>>>    any entries in an ACL or equivalent.
>>>>

---

From: Fabien Imbault <[email-masked]>
Date: Thu, 18 Mar 2021 05:07:30 +0100

Yes, the AS is the policy manager and the token issuer for that delegation,
based on the knowledge it has of the RO.
We don't assume much on the lifecycle of the protected resource, except
that they expect a valid access token issued by the AS to provide access.

We defined client instances related to one client software. The client does
matter, we could even define its class or posture, but it's possible to
make a request to the AS even if you're not pre registered.

Fabien

Le jeu. 18 mars 2021 à 04:54, Adrian Gropper <[email-masked]> a
écrit :

>>> On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault <
>>>> Le jeu. 18 mars 2021 à 00:18, Adrian Gropper <[email-masked]>
>>>> a écrit :
>>>>
>>>>> I'm sure you're right. Our vague terminology around
>>>>> client and end-user leads to my confusion. If GNAP is primarily about
>>>>> delegation then, of course, we should avoid any incentives to impersonate
>>>>> or we're wasting our time. This is partly why I'm trying to study up on
>>>>> capabilities and asking for expert advice from folks like Alan Karp and
>>>>> Mark Miller (cc'd)
>>>>>
>>>>>>> To me a VC would come under the assertions umbrella (that is to say
>>>>>>> a VC could be one type of valid assertion). The client may possess or been
>>>>>> I think you may be conflating several different kinds of parties
>>>>>> under the “client” umbrella here, though. It’s entirely possible that one
>>>>>> client might call an RS that in turn acts as a client for something else
>>>>>> down stream. But each of those hops is different from the last.
>>>>>>
>>>>>>  — Justin
>>>>>>
>>>>>>

---

From: Alan Karp <[email-masked]>
Date: Wed, 17 Mar 2021 21:03:25 -0700

How would you know if the client using the token is not the client it was
given to if the two clients are in cahoots?  Sharing tokens is actually a
useful pattern.  Client A running on your behalf could delegate to Client B
also running on your behalf, but it's sometimes easier to share the
credential.  For example, you might not mind if the client you use to
retrieve the prices of stocks in your portfolio shares permission to know
what stocks you own with the client you use to plot that data.  You would
only need to delegate if you wanted to sub-scope, separately revoke, or
have an audit trail.

--------------
Alan Karp

---

From: Alan Karp <[email-masked]>
Date: Wed, 17 Mar 2021 21:08:18 -0700

> lifecycle of the protected resource?

If tokens are certificates, the AS need not be involved in subsequent
delegations.  The AS must be involved if the tokens are opaque.

--------------
Alan Karp

---

From: Adrian Gropper <[email-masked]>
Date: Thu, 18 Mar 2021 00:21:40 -0400

... "the knowledge the AS has of the RO" is a combination of policies the
RO controls and the promise the RO received from the RS.

Once the RS has made and signed a promise in some form, why does it need to
know whether an AS was involved as long as the token has privileges that
are equal or less than the promise?

As Alan says, if the token is opaque, then of course it has to be
introspected by some entity the RS trusts, such as an AS. Was that AS set
as part of the promise made to the RO?

What does client registration have to do with any of this?

Adrian

On Thu, Mar 18, 2021 at 12:07 AM Fabien Imbault <[email-masked]>
wrote:

> Yes, the AS is the policy manager and the token issuer for that
> delegation, based on the knowledge it has of the RO.
> We defined client instances related to one client software. The client
> does matter, we could even define its class or posture, but it's possible
> to make a request to the AS even if you're not pre registered.
>
> Fabien
>
>> Also your use of "the client" seems to imply that either there is only
>> one client or the client doesn't matter. Which is it?
>>
>> Adrian
>>
>>> GNAP is defined as a delegation protocol so the main intent is related
>>> to a delegate of the RO (i.e. the end user) that wishes to access the RO's
>>>> What's vague is where the GNAP AS enters the picture as described
>>>> above. How would you describe it?
>>>>
>>>> Adrian
>>>>
>>>>
>>>>> I get the "power" neutrality is not to your liking, but RQ / user
>>>>> agent is no better in my view.
>>>>>
>>>>> Can you elaborate?
>>>>>
>>>>> Fabien
>>>>>
>>>>>>> If the client that gets the token is not same as the client that
>>>>>>> uses the token, that is a violation of core security principles as it
>>>>>>> allows for (and really designs for) impersonation by client software. I
>>>>>>> would have no reason to trust client software that would hand its
>>>>>>> credentials over to another piece of software, and in fact I shouldn’t
>>>>>>> trust it.
>>>>>>>

---

From: Fabien Imbault <[email-masked]>
Date: Thu, 18 Mar 2021 05:48:52 +0100

There are 2 different things :
- there's a generic protocol where the client doesn't need to understand
the token, based on some joint knowledge between the RS and the AS (i.e.
what these tokens represent)
- and there could be some additional assumptions (e.g. token format, RS
preflight, etc.) on how the RS gets involved in a more dynamic way.

Both views are valid, but the goal is to keep easy things simple, and allow
complex stuff too.

"if the token is opaque, then of course it has to be introspected by some
entity the RS trusts, such as an AS." not necessarily, it's entirely
possible for the RS to simply say "thanks reputable AS, I accept to process
that access token". Or you might introspect at run time. Or in some more
sensitive scenarii you might really want to go one step further and indeed
establish some agreement on what tokens mean. All I'm saying is that there
are shades in what is possible.

On your last point that's just to say that the client posture may be part
of the policy decision (since you asked if the client matters).

Fabien

Le jeu. 18 mars 2021 à 05:21, Adrian Gropper <[email-masked]> a
écrit :

> Once the RS has made and signed a promise in some form, why does it need
> to know whether an AS was involved as long as the token has privileges that
>>> On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault <
>>>> Le jeu. 18 mars 2021 à 04:29, Adrian Gropper <[email-masked]>
>>>> a écrit :
>>>>
>>>>> At various points in the lifecycle of the protected resource the
>>>>> client at the resource server (RS) might be:
>>>>>
>>>>>>>>> To me a VC would come under the assertions umbrella (that is to
>>>>>>>>> say a VC could be one type of valid assertion). The client may possess or
>>>>>>>>> been presented with a VC that it could include in its request to the AS as
>>>>>>>>> a way to identify the subject and perhaps prove authentication and
>>>>>>>>> authorization.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I do not assume that the client that interacts with the AS to make
>>>>>>>> a request and receive a token is the same as the client that will present
>>>>>>>> the token to the RS. In the US HIPAA use-case, for example, the root of
>>>>>>>> trust is a contract between the patient-subject and the doctor-requesting
>>>>>>>> party but the doctor workflow is expected to delegate the token to some
>>>>>>>> other end-user that may be using a totally different client such as an EHR.
>>>>>>>>
>>>>>>>>

---

From: Justin Richer <[email-masked]>
Date: Thu, 18 Mar 2021 07:52:56 -0400

> On Mar 18, 2021, at 12:03 AM, Alan Karp <[email-masked]> wrote:
> 
> How would you know if the client using the token is not the client it was given to if the two clients are in cahoots?  Sharing tokens is actually a useful pattern.  Client A running on your behalf could delegate to Client B also running on your behalf, but it's sometimes easier to share the credential.  For example, you might not mind if the client you use to retrieve the prices of stocks in your portfolio shares permission to know what stocks you own with the client you use to plot that data.  You would only need to delegate if you wanted to sub-scope, separately revoke, or have an audit trail. 

From the protocol's perspective, these are functionally the same client. Remember, “client instance” is a role in the system and it could be made up of many pieces of software deployed with their own internal sharing system. If two pieces of software have the same key material and token material, then they are, as far as GNAP is concerned, the same client instance. It’s important not to confuse the deployment pattern with the protocol roles.

GNAP has mechanisms to enable the kind of explicitly derived delegation that you’re describing here by allowing a client instance to ask for a new token in the context of an existing grant request or an existing access token. Those mechanisms have not been fully explored by the WG yet but they are based on the OAuth 2 token exchange concept.

 — Justin

> 
> --------------
> Alan Karp
> 
> 
> On Wed, Mar 17, 2021 at 4:18 PM Adrian Gropper <[email-masked] <mailto:[email-masked]>> wrote:

---

From: Justin Richer <[email-masked]>
Date: Thu, 18 Mar 2021 07:56:42 -0400

On Mar 18, 2021, at 12:08 AM, Alan Karp <[email-masked]> wrote:
> 
> Adrian Gropper <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Is there an AS involved in the delegation? How and where in the lifecycle of the protected resource? 
> 
> If tokens are certificates, the AS need not be involved in subsequent delegations.  The AS must be involved if the tokens are opaque. 

Tokens are opaque to the client instance. They are not opaque to the AS. They might be opaque to the RS, but that depends on the kind of relationship the RS and AS have. GNAP should allow different options here as there are different use cases for that.

It would probably be worthwhile to separate the portions of the spec that talk about the RS-AS relationship into its own standalone document. A similar approach was taken in UMA2 and it was helpful. (Though admittedly, as with anything, there are missteps there that we can hopefully learn from.)

 — Justin

> 
> --------------
> Alan Karp
> 
> 
> On Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper <[email-masked] <mailto:[email-masked]>> wrote:
> Sure! 
> 
> Is there an AS involved in the delegation? How and where in the lifecycle of the protected resource? 
> 
> Also your use of "the client" seems to imply that either there is only one client or the client doesn't matter. Which is it?
> 
> Adrian
> 
> On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault <[email-masked] <mailto:[email-masked]>> wrote:
> Thanks for that. 
> 
> Trying to reframe it:
> GNAP is defined as a delegation protocol so the main intent is related to a delegate of the RO (i.e. the end user) that wishes to access the RO's protected resources, through the client. 
> 
> Fabien 
> 
> Le jeu. 18 mars 2021 à 04:29, Adrian Gropper <[email-masked] <mailto:[email-masked]>> a écrit :
> At various points in the lifecycle of the protected resource the client at the resource server (RS) might be:
> The RO (subject) user agent trading payment for a service promise
> The RO user agent using the promise to access the protected resource
> A delegate of the RO user agent using a different client
> What's vague is where the GNAP AS enters the picture as described above. How would you describe it?
> 
> Adrian
> 
> 
> On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Adrian
> 
> I get the "power" neutrality is not to your liking, but RQ / user agent is no better in my view. 
> 
> Can you elaborate? 
> 
> Fabien 
> 
> Le jeu. 18 mars 2021 à 00:18, Adrian Gropper <[email-masked] <mailto:[email-masked]>> a écrit :

---

From: Denis <[email-masked]>
Date: Thu, 18 Mar 2021 14:39:10 +0100

Hi Justin,

You wrote:

    Tokens are opaque to the client instance.

This is certainly your point of view, but not mine. This topic is still 
under discussion under the issue #145 (Opaque / Non opaque access token)
that you would like to close next week. But it closely relates to the 
issue #214 (Trust relationships) to which you have not yet participated.

I took a look at the subject of this thread which is [GNAP] DID as 
sub_id or assertion?  We are far beyond the original topic of this thread.

Denis

> On Mar 18, 2021, at 12:08 AM, Alan Karp <[email-masked] 
> <mailto:[email-masked]>> wrote:
>>
> Tokens are opaque to the client instance. They are not opaque to the 
> AS. They might be opaque to the RS, but that depends on the kind of 
> relationship the RS and AS have. GNAP should allow different options 
> here as there are different use cases for that.
>
> It would probably be worthwhile to separate the portions of the spec 
> that talk about the RS-AS relationship into its own standalone 
> document. A similar approach was taken in UMA2 and it was helpful. 
> (Though admittedly, as with anything, there are missteps there that we 
> can hopefully learn from.)
>
>  — Justin
>
>>
>> --------------
>> Alan Karp
>>
>>
>> On Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     Sure!
>>
>>     Also your use of "the client" seems to imply that either there is
>>     only one client or the client doesn't matter. Which is it?
>>
>>     Adrian
>>
>>     On Wed, Mar 17, 2021 at 11:43 PM Fabien Imbault
>>         GNAP is defined as a delegation protocol so the main intent
>>         is related to a delegate of the RO (i.e. the end user) that
>>         wishes to access the RO's protected resources, through the
>>         client.
>>
>>         Fabien
>>
>>         Le jeu. 18 mars 2021 à 04:29, Adrian Gropper
>>         <[email-masked] <mailto:[email-masked]>> a
>>         écrit :
>>
>>             At various points in the lifecycle of the protected
>>             resource the client at the resource server (RS) might be:
>>
>>               * The RO (subject) user agent trading payment for a
>>                 service promise
>>               * The RO user agent using the promise to access the
>>                 protected resource
>>               * A delegate of the RO user agent using a different client
>>
>>             What's vague is where the GNAP AS enters the picture as
>>             described above. How would you describe it?
>>
>>             Adrian
>>
>>
>>             On Wed, Mar 17, 2021 at 10:20 PM Fabien Imbault
>>                 I get the "power" neutrality is not to your liking,
>>                 but RQ / user agent is no better in my view.
>>
>>                 Can you elaborate?
>>
>>                 Fabien
>>
>>                 Le jeu. 18 mars 2021 à 00:18, Adrian Gropper
>>                 <[email-masked]
>>                 <mailto:[email-masked]>> a écrit :
>>
>>                     I'm sure you're right. Our vague
>>                     terminology around client and end-user leads to
>>                     my confusion. If GNAP is primarily about
>>                     delegation then, of course, we should avoid any
>>                     incentives to impersonate or we're wasting our
>>                     time. This is partly why I'm trying to study up
>>                     on capabilities and asking for expert advice from
>>                     folks like Alan Karp and Mark Miller (cc'd)
>>
>>                       * store an attribute of the RO a [DID, email
>>                         address, GNAP AS URL], or
>>                       * hand the RO a capability as a sort-of promise
>>                         and avoid making any entries in an ACL or
>>                         equivalent.
>>
>>                       * validated according to something associated
>>                         with the stored RO attribute, or
>>                       * signed by the RS itself.
>>
>>                     On Wed, Mar 17, 2021 at 5:29 PM Justin Richer
>>                     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>                         On Mar 17, 2021, at 4:55 PM, Adrian Gropper
>>                         <[email-masked]
>>                         <mailto:[email-masked]>> wrote:
>>>
>>>                         On Wed, Mar 17, 2021 at 4:23 PM Tobias
>>>                         Looker <[email-masked]
>>>                         <mailto:[email-masked]>> wrote:
>>>
>>>                             <snip>
>>>                             could be one type of valid assertion).
>>>                             The client may possess or been presented
>>>                             with a VC that it could include in its
>>>                             request to the AS as a way to identify
>>>                             the subject and perhaps prove
>>>                             authentication and authorization.
>>>
>>>
>>>                         I do not assume that the client that
>>>                         interacts with the AS to make a request and
>>>                         receive a token is the same as the client
>>>                         that will present the token to the RS. In
>>>                         the US HIPAA use-case, for example, the root
>>>                         of trust is a contract between the
>>>                         patient-subject and the doctor-requesting
>>>                         party but the doctor workflow is expected to
>>>                         delegate the token to some other end-user
>>>                         that may be using a totally different client
>>>                         such as an EHR.
>>>
>>
>>                         If the client that gets the token is not same
>>                         as the client that uses the token, that is a
>>                         violation of core security principles as it
>>                         allows for (and really designs for)
>>                         impersonation by client software. I would
>>                         have no reason to trust client software that
>>                         would hand its credentials over to another
>>                         piece of software, and in fact I shouldn’t
>>                         trust it.
>>
>>                         I think you may be conflating several
>>                         different kinds of parties under the “client”
>>                         umbrella here, though. It’s entirely possible
>>                         that one client might call an RS that in turn
>>                         acts as a client for something else down

---

From: Fabien Imbault <[email-masked]>
Date: Thu, 18 Mar 2021 14:42:03 +0100

Yes I think we can close the current thread.
Compared to the original objective of the thread, I just want to summarize
what I understood as a rough consensus for the WG : go along with sub_ids,
and consider DIDs as identifiers (knowing that the demand has been pushed
to the related WG).

Best
Fabien

On Thu, Mar 18, 2021 at 2:39 PM Denis <[email-masked]> wrote:

> I took a look at the subject of this thread which is [GNAP] DID as sub_id
> or assertion?  We are far beyond the original topic of this thread.
>
> Denis
>
> Tokens are opaque to the client instance. They are not opaque to the AS.
> They might be opaque to the RS, but that depends on the kind of
> relationship the RS and AS have. GNAP should allow different options here
> as there are different use cases for that.
>
> It would probably be worthwhile to separate the portions of the spec that
> talk about the RS-AS relationship into its own standalone document. A
> similar approach was taken in UMA2 and it was helpful. (Though admittedly,
> as with anything, there are missteps there that we can hopefully learn
> from.)
>
>  — Justin
>
>
> --------------
> Alan Karp
>
>

---

From: Adrian Gropper <[email-masked]>
Date: Thu, 18 Mar 2021 10:04:20 -0400

Yes, I think we can close the current thread. Justin's explanation above of
how we're using client is clear to me.

Adrian

---

From: Alan Karp <[email-masked]>
Date: Thu, 18 Mar 2021 08:27:07 -0700

Justin Richer <[email-masked]> wrote:

>
> From the protocol's perspective, these are functionally the same client.
> Remember, “client instance” is a role in the system and it could be made up
> of many pieces of software deployed with their own internal sharing system.
> If two pieces of software have the same key material and token material,
> then they are, as far as GNAP is concerned, the same client instance. It’s
> important not to confuse the deployment pattern with the protocol roles.
>

That's exactly the right perspective.  I've been surprised by how many
people don't see it that way.

>
> GNAP has mechanisms to enable the kind of explicitly derived delegation
> that you’re describing here by allowing a client instance to ask for a new
> token in the context of an existing grant request or an existing access
> token. Those mechanisms have not been fully explored by the WG yet but they
> are based on the OAuth 2 token exchange concept.
>

You don't need token exchange if your tokens are certificates.

--------------
Alan Karp

On Thu, Mar 18, 2021 at 4:53 AM Justin Richer <[email-masked]> wrote:

> From the protocol's perspective, these are functionally the same client.
> Remember, “client instance” is a role in the system and it could be made up
> of many pieces of software deployed with their own internal sharing system.
> If two pieces of software have the same key material and token material,
> then they are, as far as GNAP is concerned, the same client instance. It’s
> important not to confuse the deployment pattern with the protocol roles.
>
> GNAP has mechanisms to enable the kind of explicitly derived delegation
> that you’re describing here by allowing a client instance to ask for a new
> token in the context of an existing grant request or an existing access
> token. Those mechanisms have not been fully explored by the WG yet but they
> are based on the OAuth 2 token exchange concept.
>
>  — Justin
>
>
> --------------
> Alan Karp
>
>

---

From: Alan Karp <[email-masked]>
Date: Thu, 18 Mar 2021 08:30:58 -0700

> as there are different use cases for that.

Tokens are not opaque to the client in SPKI, zcap-ld, Orie's implementation
with VCs, or our Zebra Copy work.  Why must they be in GNAP?

--------------
Alan Karp

---

From: Justin Richer <[email-masked]>
Date: Thu, 18 Mar 2021 12:59:39 -0400

On Mar 18, 2021, at 11:30 AM, Alan Karp <[email-masked]> wrote:
> 
> Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> On Mar 18, 2021, at 12:08 AM, Alan Karp <[email-masked] <mailto:[email-masked]>> wrote:
>> 
> Tokens are not opaque to the client in SPKI, zcap-ld, Orie's implementation with VCs, or our Zebra Copy work.  Why must they be in GNAP?

The existence of the AS is exactly the reason for this. The AS is the role that “knowledge about the token contents” has been outsourced to in the GNAP model (which is based on the OAuth model).

It brings significant simplicity for the client developer. The question I have is — why does the client need to know what’s in the token? Not if they could possibly know, but why would we expect a client to know and manage the contents of the token? 

The access token is fundamentally a conversational artifact between the AS and the RS which the client is the carrier of. The client is not the audience of the token, nor the creator of the token, nor even the manager of the token and the rights it represents. The client as a simple carrier is a powerful model that allows the security layer to get out of the way of the actual application logic that developers want to do.

 — Justin

> 
> --------------
> Alan Karp
> 
> 
> On Thu, Mar 18, 2021 at 4:56 AM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> On Mar 18, 2021, at 12:08 AM, Alan Karp <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Fabien Imbault <[email-masked]>
Date: Thu, 18 Mar 2021 18:13:27 +0100

Hi Justin,

"The access token is fundamentally a conversational artifact between the AS
and the RS which the client is the carrier of."
That's right, and a good opportunity to distinguish between the need for
token inspection (i.e. a runtime verification, wherever that may be) and
the need to negotiate the token format (a discovery). That last part could
very well be an extension, as a way to open up the ecosystem beyond JWTs
(which are fine, but come with their own limitations).

Fabien

On Thu, Mar 18, 2021 at 5:59 PM Justin Richer <[email-masked]> wrote:

> Tokens are not opaque to the client in SPKI, zcap-ld, Orie's
> implementation with VCs, or our Zebra Copy work.  Why must they be in GNAP?
>
>
> The existence of the AS is exactly the reason for this. The AS is the role
> that “knowledge about the token contents” has been outsourced to in the
> GNAP model (which is based on the OAuth model).
>
> It brings significant simplicity for the client developer. The question I
> have is — why does the client need to know what’s in the token? Not if they
> could possibly know, but why would we expect a client to know and manage
> the contents of the token?
>
> The access token is fundamentally a conversational artifact between the AS
> and the RS which the client is the carrier of. The client is not the
> audience of the token, nor the creator of the token, nor even the manager
> of the token and the rights it represents. The client as a simple carrier
> is a powerful model that allows the security layer to get out of the way of
> the actual application logic that developers want to do.
>
>  — Justin
>
>
> --------------
> Alan Karp
>
>

---

From: Denis <[email-masked]>
Date: Thu, 18 Mar 2021 18:21:01 +0100

I have changed the title of this thread, since the original topic has 
been closed.

Justin, you are raising the following question:

    The question I have is — why does the client need to know what’s in
    the token?
    Not if they could possibly know, but why would we expect a client to
    know and manage the contents of the token?

The answer is quite simple: so that the end-user may have confidence 
into the architecture.
The seventh of the eleven privacy principles from ISO 29100 (page 14) is:

    *7. Openness, transparency and notice *

If the access token is considered as a black box for the end-user, it 
cannot be confident about the content of the access token.
Such access token may disclose some private information without the 
consent of the end-user. If the access token that it has obtained
does not match with what has been requested, the client will first not 
forward the access token to the RS and then will complain about the AS.

Denis

> Hi Justin,
>
> "The access token is fundamentally a conversational artifact between 
> the AS and the RS which the client is the carrier of."
> That's right, and a good opportunity to distinguish between the need 
> for token inspection (i.e. a runtime verification, wherever that may be)
> and the need to negotiate the token format (a discovery). That last 
> part could very well be an extension, as a way to open up the ecosystem
> beyond JWTs (which are fine, but come with their own limitations).
>
> Fabien
>
> On Thu, Mar 18, 2021 at 5:59 PM Justin Richer <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     On Mar 18, 2021, at 11:30 AM, Alan Karp <[email-masked]
>>>             Is there an AS involved in the delegation? How and where
>>>             in the lifecycle of the protected resource?
>>>
>>>
>>>         If tokens are certificates, the AS need not be involved in
>>>         subsequent delegations.  The AS must be involved if the
>>>         tokens are opaque.
>>
>>         Tokens are opaque to the client instance. They are not opaque
>>         to the AS. They might be opaque to the RS, but that depends
>>         on the kind of relationship the RS and AS have. GNAP should
>>         allow different options here as there are different use cases
>>         for that.
>>
>>
>     The existence of the AS is exactly the reason for this. The AS is
>     the role that “knowledge about the token contents” has been
>     outsourced to in the GNAP model (which is based on the OAuth model).
>
>     It brings significant simplicity for the client developer. The
>     question I have is — why does the client need to know what’s in
>     the token? Not if they could possibly know, but why would we
>     expect a client to know and manage the contents of the token?
>
>     The access token is fundamentally a conversational artifact
>     between the AS and the RS which the client is the carrier of. The
>     client is not the audience of the token, nor the creator of the
>     token, nor even the manager of the token and the rights it
>     represents. The client as a simple carrier is a powerful model
>     that allows the security layer to get out of the way of the actual
>     application logic that developers want to do.
>
>      — Justin
>
>>
>>     --------------
>>     Alan Karp
>>
>>
>>>             Is there an AS involved in the delegation? How and where
>>>             in the lifecycle of the protected resource?
>>>
>>>
>>>         If tokens are certificates, the AS need not be involved in
>>>         subsequent delegations.  The AS must be involved if the
>>>         tokens are opaque.
>>
>>         Tokens are opaque to the client instance. They are not opaque
>>         to the AS. They might be opaque to the RS, but that depends
>>         on the kind of relationship the RS and AS have. GNAP should
>>         allow different options here as there are different use cases
>>         for that.
>>
>>         It would probably be worthwhile to separate the portions of
>>         the spec that talk about the RS-AS relationship into its own
>>         standalone document. A similar approach was taken in UMA2 and
>>         it was helpful. (Though admittedly, as with anything, there
>>         are missteps there that we can hopefully learn from.)
>>
>>          — Justin
>>
>>>
>>>         --------------
>>>         Alan Karp
>>>
>>>
>>>             Is there an AS involved in the delegation? How and where
>>>             in the lifecycle of the protected resource?
>>>
>>>             Also your use of "the client" seems to imply that either
>>>             there is only one client or the client doesn't matter.
>>>             Which is it?
>>>
>>>             Adrian
>>>
>>>                 GNAP is defined as a delegation protocol so the main
>>>                 intent is related to a delegate of the RO (i.e. the
>>>                 end user) that wishes to access the RO's protected
>>>                 resources, through the client.
>>>
>>>                 Fabien
>>>
>>>                     At various points in the lifecycle of the
>>>                     protected resource the client at the resource
>>>                     server (RS) might be:
>>>
>>>                       * The RO (subject) user agent trading payment
>>>                         for a service promise
>>>                       * The RO user agent using the promise to
>>>                         access the protected resource
>>>                     What's vague is where the GNAP AS enters the
>>>                     picture as described above. How would you
>>>                     describe it?
>>>
>>>                     Adrian
>>>
>>>
>>>                         I get the "power" neutrality is not to your
>>>                         liking, but RQ / user agent is no better in
>>>                         my view.
>>>
>>>                         Can you elaborate?
>>>
>>>                         Fabien
>>>
>>>                             terminology around client and end-user
>>>                             time. This is partly why I'm trying to
>>>                             study up on capabilities and asking for
>>>                             expert advice from folks like Alan Karp
>>>                             and Mark Miller (cc'd)
>>>
>>>                               * store an attribute of the RO a [DID,
>>>                                 email address, GNAP AS URL], or
>>>                               * hand the RO a capability as a
>>>                                 sort-of promise and avoid making any
>>>                               * validated according to something
>>>                                 associated with the stored RO
>>>                                 attribute, or
>>>                             On Wed, Mar 17, 2021 at 5:29 PM Justin
>>>                             Richer <[email-masked]
>>>                             <mailto:[email-masked]>> wrote:
>>>
>>>                                 On Mar 17, 2021, at 4:55 PM, Adrian
>>>                                 Gropper <[email-masked]
>>>>                                 On Wed, Mar 17, 2021 at 4:23 PM
>>>>                                 Tobias Looker
>>>>                                 <[email-masked]
>>>>                                     say a VC could be one type of
>>>>                                     valid assertion). The client
>>>>                                     may possess or been presented
>>>>                                     with a VC that it could include
>>>>                                     in its request to the AS as a
>>>>                                     way to identify the subject and
>>>>                                     perhaps prove authentication
>>>>                                     and authorization.
>>>>
>>>>
>>>>                                 a request and receive a token is
>>>>                                 the same as the client that will
>>>>                                 present the token to the RS. In the
>>>>                                 US HIPAA use-case, for example, the
>>>>                                 root of trust is a contract between
>>>>                                 the patient-subject and the
>>>>                                 doctor-requesting party but the
>>>>                                 doctor workflow is expected to
>>>>                                 delegate the token to some other
>>>>                                 end-user that may be using a
>>>>                                 totally different client such as an
>>>>                                 EHR.
>>>>
>>>
>>>                                 (and really designs for)
>>>                                 impersonation by client software. I
>>>                                 under the “client” umbrella here,
>>>                                 though. It’s entirely possible that
>>>                                 one client might call an RS that in
>>>                                 turn acts as a client for something
>>>                                 else down stream. But each of those
>>>                                 hops is different from the last.
>>>
>>>                                  — Justin
>>>
>>
>
>

---

From: Justin Richer <[email-masked]>
Date: Thu, 18 Mar 2021 13:25:46 -0400

Fabien,

Exactly, this is why I am more and more thinking that the core protocol should focus on the client instance->AS / client instance->RS connections (for which the token is opaque) and a secondary document would talk about the AS<->RS connection (for which the token is not opaque).

The mapping of the AS and RS roles is also key. In OAuth 1, these were a single entity known as the “server”. In OAuth 2, we decided to split the roles to ease the discussion of how to deploy them. OAuth 2 doesn’t say anything about how they relate to each other except that the RS trusts tokens coming from the AS. An AS could have multiple RS’s that it protects, an RS could accept tokens from multiple AS’s, these relationships could be statically configured, they could be dynamic at runtime, etc. The community has come up with two key extensions — JWTs and Introspection — that allow for interoperable ways to make this connection, but OAuth 2’s core doesn’t actually care how this happens and it could be proprietary or internal (and often times is in practice). But in all cases, the RS has outsourced its trust to the AS to create tokens the RS will accept. 

 — Justin

> On Mar 18, 2021, at 1:13 PM, Fabien Imbault <[email-masked]> wrote:
> 
> Hi Justin, 
> 
> "The access token is fundamentally a conversational artifact between the AS and the RS which the client is the carrier of."
> That's right, and a good opportunity to distinguish between the need for token inspection (i.e. a runtime verification, wherever that may be) and the need to negotiate the token format (a discovery). That last part could very well be an extension, as a way to open up the ecosystem beyond JWTs (which are fine, but come with their own limitations). 
> 
> Fabien
> 
> On Thu, Mar 18, 2021 at 5:59 PM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> On Mar 18, 2021, at 11:30 AM, Alan Karp <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Fabien Imbault <[email-masked]>
Date: Thu, 18 Mar 2021 18:28:22 +0100

+1 with that

On Thu, Mar 18, 2021 at 6:25 PM Justin Richer <[email-masked]> wrote:

> Fabien,
>
> Exactly, this is why I am more and more thinking that the core protocol
> should focus on the client instance->AS / client instance->RS connections
> (for which the token is opaque) and a secondary document would talk about
> the AS<->RS connection (for which the token is not opaque).
>
> The mapping of the AS and RS roles is also key. In OAuth 1, these were a
> single entity known as the “server”. In OAuth 2, we decided to split the
> roles to ease the discussion of how to deploy them. OAuth 2 doesn’t say
> anything about how they relate to each other except that the RS trusts
> tokens coming from the AS. An AS could have multiple RS’s that it protects,
> an RS could accept tokens from multiple AS’s, these relationships could be
> statically configured, they could be dynamic at runtime, etc. The community
> has come up with two key extensions — JWTs and Introspection — that allow
> for interoperable ways to make this connection, but OAuth 2’s core doesn’t
> actually care how this happens and it could be proprietary or internal (and
> often times is in practice). But in all cases, the RS has outsourced its
> trust to the AS to create tokens the RS will accept.
>
>  — Justin
>
> "The access token is fundamentally a conversational artifact between the
> AS and the RS which the client is the carrier of."
>> The existence of the AS is exactly the reason for this. The AS is the
>> role that “knowledge about the token contents” has been outsourced to in
>> the GNAP model (which is based on the OAuth model).
>>
>> The access token is fundamentally a conversational artifact between the
>> AS and the RS which the client is the carrier of. The client is not the
>>> that talk about the RS-AS relationship into its own standalone document. A
>>>>>>>>    - hand the RO a capability as a sort-of promise and avoid
>>>>>>>>    making any entries in an ACL or equivalent.
>>>>>>>>
>>>>>>>>    - validated according to something associated with the stored
>>>>>>>>    RO attribute, or

---

From: Stephen Moore <[email-masked]>
Date: Thu, 18 Mar 2021 13:58:54 -0400

I'm having some concerns with the way you're flipping the trust here Denis.
You seem to indicate that the user has trust in the RS and the Client and
has to gain the trust of the AS. I feel like the least trustworthy portion
of the architecture is the client, because that seems like it is the most
interchangeable component.
 Let me explain by way of a use case I have in mind.
Let's say I have a smart home. I have devices and data storage and rule
engines that are parts of sensors and hubs I buy for the house. I have a
trust in those devices, because it's hardware, if the company is leaking
data at the hardware level there isn't much I can do other than buy
different sensors.
In this case, the primary home hub, which is under control of the
homeowner, would also be the AS, as well as a policy agent.  Authentication
in the example is outsourced to whatever auth providers you want. I set up
my home using a google account, a friend is staying and wants access and
uses FB for auth... whatever.
The part that I have little control over is the client my friend uses on
his phone. Or if I change the client on the tablet in the kitchen to try
out something new. These pieces might be single page web apps, they might
be downloaded apps, etc. I do not want them having any additional
information than is necessary. If I give my friend permission to unlock the
door, and control the lights because they are feeding my cats while I'm
away, the client doesn't need to know anything beyond, I see this home
controller, and I have access to these lights and that door lock.

In your scenarios, the client is spy by design, and if it is a web app, I
don't trust them to not grab my user email address from the AS and put it
on a mailing list it sells to some sketchy company, when the only other
component that needs that information is the RS.

-steve

On Thu, Mar 18, 2021 at 1:21 PM Denis <[email-masked]> wrote:

> I have changed the title of this thread, since the original topic has been
> closed.
>
> The question I have is — why does the client need to know what’s in the
> token?
> Not if they could possibly know, but why would we expect a client to know
> and manage the contents of the token?
>
> The answer is quite simple: so that the end-user may have confidence into
> the architecture.
> token inspection (i.e. a runtime verification, wherever that may be)
> and the need to negotiate the token format (a discovery). That last part
> could very well be an extension, as a way to open up the ecosystem

---

From: Justin Richer <[email-masked]>
Date: Thu, 18 Mar 2021 14:08:45 -0400

I think Steve’s use case gives an interesting example of something that I believe Adrian’s been talking about as well — delegating to another person.

We traditionally think of delegation at the AS to mean “a different user account logs in to the AS”, and it’s important to know that this does in fact work. But this could just as easily be “Steve sends his friend an artifact to present to the AS to get access”. This isn’t Steve (or Steve’s client software) getting and sending an access token, this is sending some other set of rights credential to his friend, or his friend’s software. So then Steve’s AS can have policy that says “when I see this rights credential, give an access token for the following attenuated things, because Steve said so”. The AS doesn’t even ever need to know who Steve’s friend is! 

And importantly here, we don’t expect Steve’s friend to bring their own AS to the party. Steve’s RS has no reason to trust his friend’s AS, let alone his friend’s client. But Steve’s AS is in a position to know more about the rights policies that Steve wants to apply, and so it can use other technologies like VC’s, DIDs, OIDC, or any number of other things to let things go through. This pattern is exactly why I think we need to think of this in terms of what’s currently called “interaction” at the AS. It’s not really just about how the end-user interacts, it’s about how the AS gathers all the consent and authorization information. I plan to rewrite section 4 to that effect.

 — Justin

> On Mar 18, 2021, at 1:58 PM, Stephen Moore <[email-masked]> wrote:
> 
> I'm having some concerns with the way you're flipping the trust here Denis. You seem to indicate that the user has trust in the RS and the Client and has to gain the trust of the AS. I feel like the least trustworthy portion of the architecture is the client, because that seems like it is the most interchangeable component.
> Let's say I have a smart home. I have devices and data storage and rule engines that are parts of sensors and hubs I buy for the house. I have a trust in those devices, because it's hardware, if the company is leaking data at the hardware level there isn't much I can do other than buy different sensors.
> In this case, the primary home hub, which is under control of the homeowner, would also be the AS, as well as a policy agent.  Authentication in the example is outsourced to whatever auth providers you want. I set up my home using a google account, a friend is staying and wants access and uses FB for auth... whatever.
> The part that I have little control over is the client my friend uses on his phone. Or if I change the client on the tablet in the kitchen to try out something new. These pieces might be single page web apps, they might be downloaded apps, etc. I do not want them having any additional information than is necessary. If I give my friend permission to unlock the door, and control the lights because they are feeding my cats while I'm away, the client doesn't need to know anything beyond, I see this home controller, and I have access to these lights and that door lock.
> 
> In your scenarios, the client is spy by design, and if it is a web app, I don't trust them to not grab my user email address from the AS and put it on a mailing list it sells to some sketchy company, when the only other component that needs that information is the RS.
> 
> -steve
> 
> On Thu, Mar 18, 2021 at 1:21 PM Denis <[email-masked] <mailto:[email-masked]>> wrote:
> I have changed the title of this thread, since the original topic has been closed. 
> 
> The question I have is — why does the client need to know what’s in the token? 
> Not if they could possibly know, but why would we expect a client to know and manage the contents of the token? 
> The answer is quite simple: so that the end-user may have confidence into the architecture. 
> 7. Openness, transparency and notice 
> If the access token is considered as a black box for the end-user, it cannot be confident about the content of the access token.
> Such access token may disclose some private information without the consent of the end-user. If the access token that it has obtained 
> does not match with what has been requested, the client will first not forward the access token to the RS and then will complain about the AS.
> 
> Denis
> 
> 
>> Hi Justin, 
>> 
>> That's right, and a good opportunity to distinguish between the need for token inspection (i.e. a runtime verification, wherever that may be) 
>> and the need to negotiate the token format (a discovery). That last part could very well be an extension, as a way to open up the ecosystem

---

From: Stephen Moore <[email-masked]>
Date: Thu, 18 Mar 2021 14:26:35 -0400

That in my mind works out great... Say I'm logged into my home hub/AS.
Justin is over and agrees to cat sit, I pull up my client app, and generate
a QR code that has maybe The AS URI, the HomeHub API URL, and the 'special
token to present to AS for a real token'. Justin scans that QR code with
his home controller app, and BAM, he's onboarded as a guest without even
logging into my AS or me dealing with his Auth provider.
-steve

On Thu, Mar 18, 2021 at 2:08 PM Justin Richer <[email-masked]> wrote:

> I think Steve’s use case gives an interesting example of something that I
> believe Adrian’s been talking about as well — delegating to another person.
>
> We traditionally think of delegation at the AS to mean “a different user
> account logs in to the AS”, and it’s important to know that this does in
> fact work. But this could just as easily be “Steve sends his friend an
> artifact to present to the AS to get access”. This isn’t Steve (or Steve’s
> client software) getting and sending an access token, this is sending some
> other set of rights credential to his friend, or his friend’s software. So
> then Steve’s AS can have policy that says “when I see this rights
> credential, give an access token for the following attenuated things,
> because Steve said so”. The AS doesn’t even ever need to know who Steve’s
> friend is!
>
> And importantly here, we don’t expect Steve’s friend to bring their own AS
> to the party. Steve’s RS has no reason to trust his friend’s AS, let alone
> his friend’s client. But Steve’s AS is in a position to know more about the
> rights policies that Steve wants to apply, and so it can use other
> technologies like VC’s, DIDs, OIDC, or any number of other things to let
> things go through. This pattern is exactly why I think we need to think of
> this in terms of what’s currently called “interaction” at the AS. It’s not
> really just about how the end-user interacts, it’s about how the AS gathers
> all the consent and authorization information. I plan to rewrite section 4
> to that effect.
>
>  — Justin
>
> I'm having some concerns with the way you're flipping the trust here
> Denis. You seem to indicate that the user has trust in the RS and the
> Client and has to gain the trust of the AS. I feel like the least
> trustworthy portion of the architecture is the client, because that seems
> like it is the most interchangeable component.
>>> It brings significant simplicity for the client developer. The question
>>> I have is — why does the client need to know what’s in the token? Not if
>>> they could possibly know, but why would we expect a client to know and
>>> manage the contents of the token?
>>>
>>>>>> GNAP is defined as a delegation protocol so the main intent is
>>>>>> related to a delegate of the RO (i.e. the end user) that wishes to access
>>>>>> the RO's protected resources, through the client.
>>>>>>
>>>>>> Fabien
>>>>>>
>>>>>>>> Le jeu. 18 mars 2021 à 00:18, Adrian Gropper <
>>>>>>>> [email-masked]> a écrit :
>>>>>>>>
>>>>>>>>>> I do not assume that the client that interacts with the AS to
>>>>>>>>>> make a request and receive a token is the same as the client that will
>>>>>>>>>> present the token to the RS. In the US HIPAA use-case, for example, the
>>>>>>>>>> root of trust is a contract between the patient-subject and the
>>>>>>>>>> doctor-requesting party but the doctor workflow is expected to delegate the
>>>>>>>>>> token to some other end-user that may be using a totally different client
>>>>>>>>>> such as an EHR.
>>>>>>>>>>
>>>>>>>>>>

---

From: Justin Richer <[email-masked]>
Date: Thu, 18 Mar 2021 14:39:20 -0400

Right, and in the GNAP model this becomes something my client instance presents to the AS when I show up. The AS can validate my presentation of this item and give my client instance a token to call Steve’s RS. Or if you wanted to get super fancy Steve’s AS could even challenge my client instance and get a cryptographic response to prove I have the thing Steve had me scan. But in both cases it’s part of things that the AS collects in order to create the access token.

 — Justin

> On Mar 18, 2021, at 2:26 PM, Stephen Moore <[email-masked]> wrote:
> 
> That in my mind works out great... Say I'm logged into my home hub/AS. Justin is over and agrees to cat sit, I pull up my client app, and generate a QR code that has maybe The AS URI, the HomeHub API URL, and the 'special token to present to AS for a real token'. Justin scans that QR code with his home controller app, and BAM, he's onboarded as a guest without even logging into my AS or me dealing with his Auth provider.
> -steve
> 
> On Thu, Mar 18, 2021 at 2:08 PM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> On Mar 18, 2021, at 1:58 PM, Stephen Moore <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Adrian Gropper <[email-masked]>
Date: Thu, 18 Mar 2021 19:55:06 -0400

+1 This aligns with my healthcare use-case to the extent that Justin can
transfer the capability granted by that QR code to Adrian who happens to be
nearby Steve's house.

I've tried to capture some of this in my comment to #145
https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment-802388458

- Adrian

On Thu, Mar 18, 2021 at 2:39 PM Justin Richer <[email-masked]> wrote:

> Right, and in the GNAP model this becomes something my client instance
> presents to the AS when I show up. The AS can validate my presentation of
> this item and give my client instance a token to call Steve’s RS. Or if you
> wanted to get super fancy Steve’s AS could even challenge my client
> instance and get a cryptographic response to prove I have the thing Steve
> had me scan. But in both cases it’s part of things that the AS collects in
> order to create the access token.
>
>  — Justin
>
>> And importantly here, we don’t expect Steve’s friend to bring their own
>> AS to the party. Steve’s RS has no reason to trust his friend’s AS, let
>> alone his friend’s client. But Steve’s AS is in a position to know more
>> about the rights policies that Steve wants to apply, and so it can use
>> other technologies like VC’s, DIDs, OIDC, or any number of other things to
>> let things go through. This pattern is exactly why I think we need to think
>> of this in terms of what’s currently called “interaction” at the AS. It’s
>> not really just about how the end-user interacts, it’s about how the AS
>> gathers all the consent and authorization information. I plan to rewrite
>> section 4 to that effect.
>>
>>  — Justin
>>

---

From: Fabien Imbault <[email-masked]>
Date: Fri, 19 Mar 2021 01:16:34 +0100

Hi Adrian,

I'm really not sure I understand here.

I get the idea of putting a policy engine in front of your services to
implement ZTA. But I'm not sure I get this way of framing things. It blurs
functional roles and actual services, and most importantly if everything
gets its own AS, it also gets by transitivity its RO'/RQ' (and then its
AS-RO' etc) and so the complexity becomes staggering.
Why do we need that?

Fabien

Le ven. 19 mars 2021 à 00:55, Adrian Gropper <[email-masked]> a
écrit :

>>> I think Steve’s use case gives an interesting example of something that
>>> I believe Adrian’s been talking about as well — delegating to another
>>> person.
>>>
>>> In your scenarios, the client is spy by design, and if it is a web app,
>>> I don't trust them to not grab my user email address from the AS and put it
>>>>> question I have is — why does the client need to know what’s in the token?
>>>>> The access token is fundamentally a conversational artifact between
>>>>> the AS and the RS which the client is the carrier of. The client is not the
>>>>>> On Wed, Mar 17, 2021 at 8:54 PM Adrian Gropper <
>>>>>> [email-masked]> wrote:
>>>>>>
>>>>>>> Sure!
>>>>>>>
>>>>>>>> Le jeu. 18 mars 2021 à 04:29, Adrian Gropper <
>>>>>>>>>>>    - validated according to something associated with the
>>>>>>>>>>>    stored RO attribute, or
>>>>>>>>>>>>> To me a VC would come under the assertions umbrella (that is
>>>>>>>>>>>>> to say a VC could be one type of valid assertion). The client may possess
>>>>>>>>>>>>> or been presented with a VC that it could include in its request to the AS
>>>>>>>>>>>>> as a way to identify the subject and perhaps prove authentication and
>>>>>>>>>>>>> authorization.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> If the client that gets the token is not same as the client
>>>>>>>>>>>> that uses the token, that is a violation of core security principles as it
>>>>>>>>>>>> I think you may be conflating several different kinds of
>>>>>>>>>>>> parties under the “client” umbrella here, though. It’s entirely possible
>>>>>>>>>>>> that one client might call an RS that in turn acts as a client for
>>>>>>>>>>>> something else down stream. But each of those hops is different from the
>>>>>>>>>>>> last.
>>>>>>>>>>>>
>>>>>>>>>>>>  — Justin
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>> --
>>>> TXAuth mailing list
>>>> [email-masked]

---

From: Alejandro Iacobelli <[email-masked]>
Date: Thu, 18 Mar 2021 21:23:59 -0300

The decision about "opaque" vs "sealed but recoverable" or "signed"
access_token goes way back on the stateless protocols session management.

In my opinion, the software design principle that we must apply here is the
"need to know" principle. This means, the less information an attacker
could get, the better. One thing that JWS explse is all the context
information about a token, so an attacker can get lots of information just
with a look.

The next discussion will be what ways of generating opaque tokens are there
and which must we choose (Encrypted vs CSPRNG based).

On Thu, 18 Mar 2021 at 21:17, Fabien Imbault <[email-masked]>
wrote:

>>>> We traditionally think of delegation at the AS to mean “a different
>>>> user account logs in to the AS”, and it’s important to know that this does
>>>> in fact work. But this could just as easily be “Steve sends his friend an
>>>> The part that I have little control over is the client my friend uses
>>>> on his phone. Or if I change the client on the tablet in the kitchen to try
>>>>>>> subsequent delegations.  The AS must be involved if the tokens are opaque.
>>>>>>>
>>>>>>>
>>>>>>> subsequent delegations.  The AS must be involved if the tokens are opaque.
>>>>>>>
>>>>>>>

-- 
You know nothing Jon Snow!

---

From: Adrian Gropper <[email-masked]>
Date: Thu, 18 Mar 2021 21:03:51 -0400

I'm not a security person. I do, however, have a lot of experience with
regulatory practices as relates to safety in medical devices and business.
I see the security struggles of today as being an over-reliance on
institutional trust and a lack of effective audit and individual
accountability. I see great promise in moving advanced crypto to the
individual through DIDs and VCs and then using these identity-based
components in protocols like GNAP that are directly in the security, audit,
and accountability role. DIDs, VCs, and capabilities, to me, are just data
models.

I know that's a very vague and philosophical answer to give to architects
like the folks in this group. Sorry.

>From this perspective, GNAP is where we get to introduce
individual accountability, resilience against single points of failure,
practical audit mechanisms, and the benefit of a decade of
blockchain-driven cryptography advances. I don't see GNAP as complicated,
but what do I know?

Adrian

On Thu, Mar 18, 2021 at 8:24 PM Alejandro Iacobelli <
[email-masked]> wrote:

> In my opinion, the software design principle that we must apply here is
> the "need to know" principle. This means, the less information an attacker
> The next discussion will be what ways of generating opaque tokens are
> there and which must we choose (Encrypted vs CSPRNG based).
>
>>>>> I think Steve’s use case gives an interesting example of something
>>>>> that I believe Adrian’s been talking about as well — delegating to another
>>>>> person.
>>>>>
>>>>> And importantly here, we don’t expect Steve’s friend to bring their
>>>>> own AS to the party. Steve’s RS has no reason to trust his friend’s AS, let
>>>>> Let's say I have a smart home. I have devices and data storage and
>>>>> rule engines that are parts of sensors and hubs I buy for the house. I have
>>>>> a trust in those devices, because it's hardware, if the company is leaking
>>>>> In your scenarios, the client is spy by design, and if it is a web
>>>>> app, I don't trust them to not grab my user email address from the AS and
>>>>> put it on a mailing list it sells to some sketchy company, when the only
>>>>> other component that needs that information is the RS.
>>>>>
>>>>> -steve
>>>>>
>>>>>> does not match with what has been requested, the client will first
>>>>>> not forward the access token to the RS and then will complain about the AS.
>>>>>>
>>>>>> Denis
>>>>>>
>>>>>>
>>>>>> Hi Justin,
>>>>>>
>>>>>>>> Tokens are opaque to the client instance. They are not opaque to
>>>>>>>> the AS. They might be opaque to the RS, but that depends on the kind of
>>>>>>> the role that “knowledge about the token contents” has been outsourced to
>>>>>>> in the GNAP model (which is based on the OAuth model).
>>>>>>>
>>>>>>>> Tokens are opaque to the client instance. They are not opaque to
>>>>>>>> the AS. They might be opaque to the RS, but that depends on the kind of
>>>>>>>> It would probably be worthwhile to separate the portions of the
>>>>>>>> spec that talk about the RS-AS relationship into its own standalone
>>>>>>>> document. A similar approach was taken in UMA2 and it was helpful. (Though
>>>>>>>> admittedly, as with anything, there are missteps there that we can
>>>>>>>> hopefully learn from.)
>>>>>>>>
>>>>>>>>  — Justin
>>>>>>>>
>>>>>>>>
>>>>>>>> --------------
>>>>>>>> Alan Karp
>>>>>>>>
>>>>>>>>

---

From: Justin Richer <[email-masked]>
Date: Fri, 19 Mar 2021 09:04:10 -0400

One of the best ways to protect information in the token is to not put it in the token in the first place. This is why a some highly-sensitive application profiles and deployments us randomized values as tokens. The RS has a way to dereference it, which is important.

For downstream delegation, like one micro service calling another, we’re no longer talking about the client knowing the access token, we’re talking about an RS at the first step. This is where non-opaque, or encrypted, or other kinds of recoverable data structures come into play more directly. 

To Adrian’s point, sharing the QR code should be up to the AS’s policy. If Steve gives me a bearer artifact that isn’t attached to anything that identifies me, then it’s easy for me to share because the artifact is the identity and proof all in one. The strawman description below sounds like that. But it’s important in this design that the AS can also require me to log in with a specific account, plus present a token, plus type in a secret code, plus present a hardware key that completes a circuit in the right way (seems like something Steve would build, tbh), etc. But all of these aren’t a client talking to a resource, they’re the end-user  presenting things to the AS so that the AS can make a policy decision to issue a token and allow access. 

 — Justin

> On Mar 18, 2021, at 8:23 PM, Alejandro Iacobelli <[email-masked]> wrote:
> 
> The decision about "opaque" vs "sealed but recoverable" or "signed" access_token goes way back on the stateless protocols session management. 
> 
> In my opinion, the software design principle that we must apply here is the "need to know" principle. This means, the less information an attacker could get, the better. One thing that JWS explse is all the context information about a token, so an attacker can get lots of information just with a look. 
> 
> The next discussion will be what ways of generating opaque tokens are there and which must we choose (Encrypted vs CSPRNG based).
> 
> On Thu, 18 Mar 2021 at 21:17, Fabien Imbault <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Adrian,
> 
> I get the idea of putting a policy engine in front of your services to implement ZTA. But I'm not sure I get this way of framing things. It blurs functional roles and actual services, and most importantly if everything gets its own AS, it also gets by transitivity its RO'/RQ' (and then its AS-RO' etc) and so the complexity becomes staggering. 
> Why do we need that? 
> 
> Fabien 
> 
> Le ven. 19 mars 2021 à 00:55, Adrian Gropper <[email-masked] <mailto:[email-masked]>> a écrit :
> +1 This aligns with my healthcare use-case to the extent that Justin can transfer the capability granted by that QR code to Adrian who happens to be nearby Steve's house.
> 
> I've tried to capture some of this in my comment to #145 https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment-802388458 <https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/145#issuecomment-802388458>
> 
> - Adrian
> 
> On Thu, Mar 18, 2021 at 2:39 PM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> On Mar 18, 2021, at 2:26 PM, Stephen Moore <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Alejandro Iacobelli <[email-masked]>
Date: Fri, 19 Mar 2021 12:13:07 -0300

Agree! So what are you saying the proposal should be? Random or sealed
tokens?

El El vie, 19 mar. 2021 a la(s) 10:04, Justin Richer <[email-masked]>
escribió:

> One of the best ways to protect information in the token is to not put it
> in the token in the first place. This is why a some highly-sensitive
> application profiles and deployments us randomized values as tokens. The RS
> has a way to dereference it, which is important.
>
> For downstream delegation, like one micro service calling another, we’re
> no longer talking about the client knowing the access token, we’re talking
> about an RS at the first step. This is where non-opaque, or encrypted, or
> other kinds of recoverable data structures come into play more directly.
>
> To Adrian’s point, sharing the QR code should be up to the AS’s policy. If
> Steve gives me a bearer artifact that isn’t attached to anything that
> identifies me, then it’s easy for me to share because the artifact is the
> identity and proof all in one. The strawman description below sounds like
> that. But it’s important in this design that the AS can also require me to
> log in with a specific account, plus present a token, plus type in a secret
> code, plus present a hardware key that completes a circuit in the right way
> (seems like something Steve would build, tbh), etc. But all of these aren’t
> a client talking to a resource, they’re the end-user  presenting things to
> the AS so that the AS can make a policy decision to issue a token and allow
> access.
>
>  — Justin
>

---

From: Justin Richer <[email-masked]>
Date: Fri, 19 Mar 2021 11:37:09 -0400

My proposal is that the client instance shouldn’t care what’s in the token, what format it is, etc.

The RS can care and there should be choices that include random, sealed, and even plainly signed tokens. That choice is part of the relationship between the RS and AS, which the core GNAP protocol doesn’t specify. 

This is why I propose that we extract what’s now section 10 in the draft and put it into a new document that can more directly discuss that relationship. These different relationships should be modular. 

 — Justin

> On Mar 19, 2021, at 11:13 AM, Alejandro Iacobelli <[email-masked]> wrote:
> 
> Agree! So what are you saying the proposal should be? Random or sealed tokens?
> 
> El El vie, 19 mar. 2021 a la(s) 10:04, Justin Richer <[email-masked] <mailto:[email-masked]>> escribió:
>> On Mar 18, 2021, at 8:23 PM, Alejandro Iacobelli <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Adrian Gropper <[email-masked]>
Date: Fri, 19 Mar 2021 12:37:22 -0400

It might be a good idea to keep the RS to AS relationship out of the GNAP
spec but I’m having a hard time analyzing it in the abstract.

My starting perspective is that the RS should not know or care whether it
is dealing with the AS or the RO. This is super important because it gives
the RO unlimited delegation power.

Cases where the RO wants to give the RS a separate endpoint or other
identity should be allowed by GNAP but might be out of band. This is the
HIPAA API Task Force use case that I have referenced in another thread. The
issue here is that the RS has the option of reaching out to the RO and
requesting confirmation.

Adrian

On Fri, Mar 19, 2021 at 11:37 AM Justin Richer <[email-masked]> wrote:

> The RS can care and there should be choices that include random, sealed,
> and even plainly signed tokens. That choice is part of the relationship
> between the RS and AS, which the core GNAP protocol doesn’t specify.
>
> This is why I propose that we extract what’s now section 10 in the draft
> and put it into a new document that can more directly discuss that
> relationship. These different relationships should be modular.
>
>  — Justin
>
>> To Adrian’s point, sharing the QR code should be up to the AS’s policy.
>> If Steve gives me a bearer artifact that isn’t attached to anything that
>>>> +1 This aligns with my healthcare use-case to the extent that Justin
>>>> can transfer the capability granted by that QR code to Adrian who happens
>>>> to be nearby Steve's house.
>>>>
>>>>>>> If the access token is considered as a black box for the end-user,
>>>>>>> it cannot be confident about the content of the access token.
>>>>>>>>>>>> At various points in the lifecycle of the protected resource
>>>>>>>>>>>> the client at the resource server (RS) might be:
>>>>>>>>>>>>
>>>>>>>>>>>>>>>> To me a VC would come under the assertions umbrella (that
>>>>>>>>>>>>>>>> is to say a VC could be one type of valid assertion). The client may
>>>>>>>>>>>>>>>> possess or been presented with a VC that it could include in its request to
>>>>>>>>>>>>>>>> the AS as a way to identify the subject and perhaps prove authentication
>>>>>>>>>>>>>>>> and authorization.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I do not assume that the client that interacts with the AS
>>>>>>>>>>>>>>> to make a request and receive a token is the same as the client that will

---

From: Justin Richer <[email-masked]>
Date: Fri, 19 Mar 2021 13:21:44 -0400

There’s an important difference here:

The AS is software. Always. It plays a specific role within the protocol.

The RO could be a person. It could be an agency. It could be a policy. They don’t take part in the protocol directly but are involved in decisions made in the course of the protocol.

These are two very, very different things, and they can’t be conflated.

I like the idea of talking in terms of relationships, such as AS-RS (a protocol relationship) and AS-RO (a trust relationship). 

 — Justin

> On Mar 19, 2021, at 12:37 PM, Adrian Gropper <[email-masked]> wrote:
> 
> It might be a good idea to keep the RS to AS relationship out of the GNAP spec but I’m having a hard time analyzing it in the abstract. 
> 
> My starting perspective is that the RS should not know or care whether it is dealing with the AS or the RO. This is super important because it gives the RO unlimited delegation power. 
> 
> Cases where the RO wants to give the RS a separate endpoint or other identity should be allowed by GNAP but might be out of band. This is the HIPAA API Task Force use case that I have referenced in another thread. The issue here is that the RS has the option of reaching out to the RO and requesting confirmation.
> 
> Adrian  
> 
> On Fri, Mar 19, 2021 at 11:37 AM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> On Mar 19, 2021, at 11:13 AM, Alejandro Iacobelli <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Adrian Gropper <[email-masked]>
Date: Fri, 19 Mar 2021 13:26:34 -0400

I agree. The problem is that powerful RS operators introduce things like
Capchas that hassle the RO. Sometimes this is justified but often it
reflects an inadequate protocol.

Adrian

On Fri, Mar 19, 2021 at 1:22 PM Justin Richer <[email-masked]> wrote:

> The RO could be a person. It could be an agency. It could be a policy.
> They don’t take part in the protocol directly but are involved in decisions
> made in the course of the protocol.
>
> I like the idea of talking in terms of relationships, such as AS-RS (a
> protocol relationship) and AS-RO (a trust relationship).
>
>  — Justin
>
>>> One of the best ways to protect information in the token is to not put
>>> it in the token in the first place. This is why a some highly-sensitive
>>>> Le ven. 19 mars 2021 à 00:55, Adrian Gropper <[email-masked]>
>>>> a écrit :
>>>>
>>>>>> Right, and in the GNAP model this becomes something my client
>>>>>> instance presents to the AS when I show up. The AS can validate my
>>>>>> presentation of this item and give my client instance a token to call
>>>>>> Steve’s RS. Or if you wanted to get super fancy Steve’s AS could even
>>>>>> challenge my client instance and get a cryptographic response to prove I
>>>>>> have the thing Steve had me scan. But in both cases it’s part of things
>>>>>> that the AS collects in order to create the access token.
>>>>>>
>>>>>>  — Justin
>>>>>>
>>>>>> That in my mind works out great... Say I'm logged into my home
>>>>>> hub/AS. Justin is over and agrees to cat sit, I pull up my client app, and
>>>>>> generate a QR code that has maybe The AS URI, the HomeHub API URL, and the
>>>>>> 'special token to present to AS for a real token'. Justin scans that QR
>>>>>> code with his home controller app, and BAM, he's onboarded as a guest
>>>>>> without even logging into my AS or me dealing with his Auth provider.
>>>>>> -steve
>>>>>>
>>>>>>> The part that I have little control over is the client my friend
>>>>>>> uses on his phone. Or if I change the client on the tablet in the kitchen
>>>>>>> to try out something new. These pieces might be single page web apps, they
>>>>>>> might be downloaded apps, etc. I do not want them having any additional
>>>>>>>> Not if they could possibly know, but why would we expect a client
>>>>>>>> to know and manage the contents of the token?
>>>>>>>>
>>>>>>>> "The access token is fundamentally a conversational artifact
>>>>>>>> between the AS and the RS which the client is the carrier of."
>>>>>>>> That's right, and a good opportunity to distinguish between the
>>>>>>>> need for token inspection (i.e. a runtime verification, wherever that may
>>>>>>>> be)
>>>>>>>>> between the AS and the RS which the client is the carrier of. The client is
>>>>>>>>> not the audience of the token, nor the creator of the token, nor even the
>>>>>>>>> manager of the token and the rights it represents. The client as a simple
>>>>>>>>> carrier is a powerful model that allows the security layer to get out of
>>>>>>>>> the way of the actual application logic that developers want to do.
>>>>>>>>>
>>>>>>>>>  — Justin
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --------------
>>>>>>>>> Alan Karp
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> Also your use of "the client" seems to imply that either there
>>>>>>>>>>> is only one client or the client doesn't matter. Which is it?
>>>>>>>>>>>
>>>>>>>>>>> Adrian
>>>>>>>>>>>
>>>>>>>>>>>>>>>    - hand the RO a capability as a sort-of promise and
>>>>>>>>>>>>>>>    avoid making any entries in an ACL or equivalent.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> > A client might not have a DID but it could have a VC as
>>>>>>>>>>>>>>>>> a certificate of authenticity linked to some audit mechanism.
>>>>>>>>>>>>>>>>>

---

From: Justin Richer <[email-masked]>
Date: Fri, 19 Mar 2021 13:32:21 -0400

The only way for the RS operator could introduce a captcha, within the definitions of the GNAP protocol, is through an AS. Or more properly, through this yes-unnamed aspect of “interacting with the RO” that the AS is in charge of coordinating the results of. The RS is not an end-user-facing service, it is an API, software meant to be called by other software. The defined way for the “RS” to interact with a person, issue tokens, or anything of the sort is through an AS. 

In OAuth 1, the AS and RS were just called the “authorization server” or even just “server", and it seems like a lot of the discussion on this thread is collapsing that same set of roles back but instead calling it the “RS”. I think this is problematic both in terms of the flexibility of the protocol and also in terms of clarity in what we’re describing and discussing. 

 — Justin

> On Mar 19, 2021, at 1:26 PM, Adrian Gropper <[email-masked]> wrote:
> 
> I agree. The problem is that powerful RS operators introduce things like Capchas that hassle the RO. Sometimes this is justified but often it reflects an inadequate protocol. 
> 
> Adrian
> 
> On Fri, Mar 19, 2021 at 1:22 PM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> On Mar 19, 2021, at 12:37 PM, Adrian Gropper <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Fabien Imbault <[email-masked]>
Date: Fri, 19 Mar 2021 18:38:22 +0100

Oh I thought capchas were mostly a way to train your AI for free ;-)

Joke aside, I support Justin's view of what goes into core versus what the
kind of modularity we might bring in addition to that.

Fabien

On Fri, Mar 19, 2021 at 6:32 PM Justin Richer <[email-masked]> wrote:

> The only way for the RS operator could introduce a captcha, within the
> definitions of the GNAP protocol, is through an AS. Or more properly,
> through this yes-unnamed aspect of “interacting with the RO” that the AS is
> in charge of coordinating the results of. The RS is not an end-user-facing
> service, it is an API, software meant to be called by other software. The
> defined way for the “RS” to interact with a person, issue tokens, or
> anything of the sort is through an AS.
>
> In OAuth 1, the AS and RS were just called the “authorization server” or
> even just “server", and it seems like a lot of the discussion on this
> thread is collapsing that same set of roles back but instead calling it the
> “RS”. I think this is problematic both in terms of the flexibility of the
> protocol and also in terms of clarity in what we’re describing and
> discussing.
>
>  — Justin
>
>>>> For downstream delegation, like one micro service calling another,
>>>> we’re no longer talking about the client knowing the access token, we’re
>>>> talking about an RS at the first step. This is where non-opaque, or
>>>> encrypted, or other kinds of recoverable data structures come into play
>>>> more directly.
>>>>
>>>>>>>> I'm having some concerns with the way you're flipping the trust
>>>>>>>> here Denis. You seem to indicate that the user has trust in the RS and the
>>>>>>>>> Such access token may disclose some private information without
>>>>>>>>> the consent of the end-user. If the access token that it has obtained
>>>>>>>>>
>>>>>>>>> and the need to negotiate the token format (a discovery). That
>>>>>>>>> last part could very well be an extension, as a way to open up the ecosystem
>>>>>>>>>
>>>>>>>>>>>>>>>>> If the client that gets the token is not same as the
>>>>>>>>>>>>>>>>> client that uses the token, that is a violation of core security principles
>>>>>>>>>>>>>>>>> as it allows for (and really designs for) impersonation by client software.
>>>>>>>>>>>>>>>>> I would have no reason to trust client software that would hand its

---

From: Adrian Gropper <[email-masked]>
Date: Fri, 19 Mar 2021 14:23:15 -0400

I'm not disagreeing, just reserving judgement until I see a PR about this
AS-RS idea.

My mention of the Capcha was a shortcut and a bad example. What I meant to
say is that relying parties, the RS in this case, can make demands. FIDO,
for example, can demand a certificate signed by some trusted entity and
that a person touch a thing.

As Justin says, the RO could be a person - but it could also be a thing or
an entity or software. So, I'm not sure where we're headed and look forward
to a proposal.

Adrian

On Fri, Mar 19, 2021 at 1:38 PM Fabien Imbault <[email-masked]>
wrote:

>>> It might be a good idea to keep the RS to AS relationship out of the
>>> GNAP spec but I’m having a hard time analyzing it in the abstract.
>>>
>>> My starting perspective is that the RS should not know or care whether
>>> it is dealing with the AS or the RO. This is super important because it
>>> gives the RO unlimited delegation power.
>>>
>>>> The RS can care and there should be choices that include random,
>>>> sealed, and even plainly signed tokens. That choice is part of the
>>>> relationship between the RS and AS, which the core GNAP protocol doesn’t
>>>> specify.
>>>>
>>>> This is why I propose that we extract what’s now section 10 in the
>>>> draft and put it into a new document that can more directly discuss that
>>>>> To Adrian’s point, sharing the QR code should be up to the AS’s
>>>>> policy. If Steve gives me a bearer artifact that isn’t attached to anything
>>>>> that identifies me, then it’s easy for me to share because the artifact is
>>>>> the identity and proof all in one. The strawman description below sounds
>>>>> like that. But it’s important in this design that the AS can also require
>>>>> me to log in with a specific account, plus present a token, plus type in a
>>>>> secret code, plus present a hardware key that completes a circuit in the
>>>>> right way (seems like something Steve would build, tbh), etc. But all of
>>>>> these aren’t a client talking to a resource, they’re the end-user
>>>>>  presenting things to the AS so that the AS can make a policy decision to
>>>>> issue a token and allow access.
>>>>>
>>>>>  — Justin
>>>>>
>>>>> In my opinion, the software design principle that we must apply here
>>>>> is the "need to know" principle. This means, the less information an
>>>>> attacker could get, the better. One thing that JWS explse is all the
>>>>> context information about a token, so an attacker can get lots of
>>>>> information just with a look.
>>>>>
>>>>>> I get the idea of putting a policy engine in front of your services
>>>>>> to implement ZTA. But I'm not sure I get this way of framing things. It
>>>>>> blurs functional roles and actual services, and most importantly if
>>>>>> everything gets its own AS, it also gets by transitivity its RO'/RQ' (and
>>>>>> then its AS-RO' etc) and so the complexity becomes staggering.
>>>>>> Why do we need that?
>>>>>>
>>>>>> Fabien
>>>>>>
>>>>>>>>> We traditionally think of delegation at the AS to mean “a
>>>>>>>>> different user account logs in to the AS”, and it’s important to know that
>>>>>>>>> this does in fact work. But this could just as easily be “Steve sends his
>>>>>>>>> friend an artifact to present to the AS to get access”. This isn’t Steve
>>>>>>>>> (or Steve’s client software) getting and sending an access token, this is
>>>>>>>>> sending some other set of rights credential to his friend, or his friend’s
>>>>>>>>> software. So then Steve’s AS can have policy that says “when I see this
>>>>>>>>> rights credential, give an access token for the following attenuated
>>>>>>>>> things, because Steve said so”. The AS doesn’t even ever need to know who
>>>>>>>>> Steve’s friend is!
>>>>>>>>>
>>>>>>>>> And importantly here, we don’t expect Steve’s friend to bring
>>>>>>>>> their own AS to the party. Steve’s RS has no reason to trust his friend’s
>>>>>>>>> AS, let alone his friend’s client. But Steve’s AS is in a position to know
>>>>>>>>> more about the rights policies that Steve wants to apply, and so it can use
>>>>>>>>>> If the access token is considered as a black box for the
>>>>>>>>>> end-user, it cannot be confident about the content of the access token.
>>>>>>>>>> does not match with what has been requested, the client will
>>>>>>>>>> first not forward the access token to the RS and then will complain about
>>>>>>>>>> the AS.
>>>>>>>>>>
>>>>>>>>>> Denis
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi Justin,
>>>>>>>>>>
>>>>>>>>>>>> to the AS. They might be opaque to the RS, but that depends on the kind of
>>>>>>>>>>> The existence of the AS is exactly the reason for this. The AS
>>>>>>>>>>> is the role that “knowledge about the token contents” has been outsourced
>>>>>>>>>>> to in the GNAP model (which is based on the OAuth model).
>>>>>>>>>>>
>>>>>>>>>>>> to the AS. They might be opaque to the RS, but that depends on the kind of
>>>>>>>>>>>>>> is related to a delegate of the RO (i.e. the end user) that wishes to
>>>>>>>>>>>>>> access the RO's protected resources, through the client.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Fabien
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> > A client might not have a DID but it could have a VC
>>>>>>>>>>>>>>>>>>> as a certificate of authenticity linked to some audit mechanism.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> To me a VC would come under the assertions umbrella
>>>>>>>>>>>>>>>>>>> (that is to say a VC could be one type of valid assertion). The client may
>>>>>>>>>>>>>>>>>> I do not assume that the client that interacts with the
>>>>>>>>>>>>>>>>>> AS to make a request and receive a token is the same as the client that
>>>>>>>>>>>>>>>>>> will present the token to the RS. In the US HIPAA use-case, for example,
>>>>>>>>>>>>>>>>>> the root of trust is a contract between the patient-subject and the