Subject: [GNAP] Integrating a GNAP AS with wallets and SSI

From: Justin Richer <[email-masked]>
Date: Wed, 17 Feb 2021 17:27:30 -0500

The last interim call had a lot of discussion on SSI technologies such as digital wallets, and how those fit with GNAP. I think it’s worth continuing that conversation here on the list. There are a few issues in the tracker that give some background, too:

https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/175 <https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/175>

There’s been a lot of interesting work recently in the OpenID Foundation around using the Self-issued OP (SIOP) functionality to bootstrap an SSI style login. This makes extensive use of the implicit flow and front channel messaging, but minimization of the front channel for message passing is a key design tenet of GNAP (so much so that it’s included in our charter). Instead, GNAP has been built around an idea that everything starts the same way: with an HTTP request to the AS. 

The idea of an on-device AS has been brought up a lot, and we need to consider if and how we want to deal with these kinds of use cases. The most obvious way to address these would be to do some kind of clever off-HTTP hack like SIOP, but keep in mind that even SIOP generally starts off with an HTTP-based discovery call by the RP to make things work.

My personal stance is that to do this, we need to re-evaluate our assumptions about exactly what an AS does and what it needs to do those things. In OAuth 2, it’s assumed that the AS is the device that’s authenticating the user, collecting consent, managing the client’s registration, and creating an access token based on whatever set of rights that are associated with all of those things. In UMA, this is turned around a bit by letting the RO present a bunch of nebulous “claims” interactively, but still at the AS. 

With both of these, a key aspect remains: the AS needs to gather necessary information, and issue the access token (or identifiers/assertions). Because of how the protocol works, the client software now has a better opportunity to present information to the AS, either directly in the request or by introducing the AS to another software component during the “interaction” phase. So, what if we think of the AS primarily as a “token issuer”? 

For example, if the client can present a verifiable credential (VC) that represents the end user, the AS can validate that VC and make an access token on behalf of that user, without having the user log in or interact with the AS at all. This VC can contain whatever access rights the token needs to represent, and the AS can translate that into an artifact that the downstream RS’s can interpret, without having to see the original VC or the user at all. The AS is still HTTP based, but all the essential security and rights elements are provided by the wallet. In this way, we can expand on the privacy-preserving aspects of OAuth and bridge the worlds of SSI and web APIs without violating the basic nature of either.

Coming from the OAuth world, it feels weird to issue tokens like this, but there’s precedent for this kind of thing. Today, a there are a number of service-based OAuth AS's that are told what claims need to get put into the access token by some trusted component. All of this happens outside the OAuth protocol. In GNAP, I think it makes sense to account for this kind of thing in how we define the protocol. That isn’t to say all of these pieces need to be defined in the core, but the base protocol ought to be able to handle being extended in this direction as needed.

I’m really interested to hear other people’s thoughts on how this could come together.

 — Justin

---

From: Fabien Imbault <[email-masked]>
Date: Thu, 18 Feb 2021 09:19:00 +0100

Hi Justin,

I agree that defining AS role primarily as a token issuer is a fruitful
idea. Solving this problem well would also respond to the challenges
discussed previously on the list.

Cheers
Fabien

Le mer. 17 févr. 2021 à 23:27, Justin Richer <[email-masked]> a écrit :

> The last interim call had a lot of discussion on SSI technologies such as
> digital wallets, and how those fit with GNAP. I think it’s worth continuing
> that conversation here on the list. There are a few issues in the tracker
> that give some background, too:
>
> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/175
>
> There’s been a lot of interesting work recently in the OpenID Foundation
> around using the Self-issued OP (SIOP) functionality to bootstrap an SSI
> style login. This makes extensive use of the implicit flow and front
> channel messaging, but minimization of the front channel for message
> passing is a key design tenet of GNAP (so much so that it’s included in our
> charter). Instead, GNAP has been built around an idea that everything
> starts the same way: with an HTTP request to the AS.
>
> The idea of an on-device AS has been brought up a lot, and we need to
> consider if and how we want to deal with these kinds of use cases. The most
> obvious way to address these would be to do some kind of clever off-HTTP
> hack like SIOP, but keep in mind that even SIOP generally starts off with
> an HTTP-based discovery call by the RP to make things work.
>
> My personal stance is that to do this, we need to re-evaluate our
> assumptions about exactly what an AS does and what it needs to do those
> things. In OAuth 2, it’s assumed that the AS is the device that’s
> authenticating the user, collecting consent, managing the client’s
> registration, and creating an access token based on whatever set of rights
> that are associated with all of those things. In UMA, this is turned around
> a bit by letting the RO present a bunch of nebulous “claims” interactively,
> but still at the AS.
>
> With both of these, a key aspect remains: the AS needs to gather necessary
> information, and issue the access token (or identifiers/assertions).
> Because of how the protocol works, the client software now has a better
> opportunity to present information to the AS, either directly in the
> request or by introducing the AS to another software component during the
> “interaction” phase. So, what if we think of the AS primarily as a “token
> issuer”?
>
> For example, if the client can present a verifiable credential (VC) that
> represents the end user, the AS can validate that VC and make an access
> token on behalf of that user, without having the user log in or interact
> with the AS at all. This VC can contain whatever access rights the token
> needs to represent, and the AS can translate that into an artifact that the
> downstream RS’s can interpret, without having to see the original VC or the
> user at all. The AS is still HTTP based, but all the essential security and
> rights elements are provided by the wallet. In this way, we can expand on
> the privacy-preserving aspects of OAuth and bridge the worlds of SSI and
> web APIs without violating the basic nature of either.
>
> Coming from the OAuth world, it feels weird to issue tokens like this, but
> there’s precedent for this kind of thing. Today, a there are a number of
> service-based OAuth AS's that are told what claims need to get put into the
> access token by some trusted component. All of this happens outside the
> OAuth protocol. In GNAP, I think it makes sense to account for this kind of
> thing in how we define the protocol. That isn’t to say all of these pieces
> need to be defined in the core, but the base protocol ought to be able to
> handle being extended in this direction as needed.
>
> --
> TXAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth
>

---

From: Tobias Looker <[email-masked]>
Date: Fri, 19 Feb 2021 13:59:33 +1300

Justin,

I think this is a great and timely conversation to be having given the
current interest around SSI and efforts like SIOP, I have been doing quite
a bit of work in this space as of recent, so thought I'd add a few of the
observations that I've made.

In my opinion SIOP was really a bucket for solving quite a few different
problems, not just one. In particular I think its intent was to solve 3
major ones:

1. Enabling portable identities
2. Solving the NASCAR problem
3. Exploring different deployment models for the provider

To drill down briefly on these, note much of my terminology is OpenID based
due to SIOPs origin

*Enabling portable identities *- In general today in the case of OpenID,
the end-users identity as understood by a relying party is scoped within
the domain of the provider. Which means if that provider goes out of
business or for whatever reason decides to no longer offer the same
identity services to the End-User, their identity is essentially gone.
Whilst there has been some interesting related work from groups like MODRNA
on solutions to combat this like 'Account Porting', they often assume the
old provider remains online and willing to facilitate in the account
porting process so that the End-User can migrate to a new provider. SIOP
actually elected to do something different here by using cryptography,
instead of the End-User identifier being something like a GUID asserted
within the domain of the provider, SIOP defined this instead as a public
key fingerprint associated to a private key that's assumed to be under the
control of the user. In doing so the identity itself becomes portable
between providers by transferring the associated private key. Now this
approach does have drawbacks and arguably encourages what many would refer
to as bad cryptographic practise by not allowing any way to do key
rotation, however the idea was there.

*How GNAP can solve for this?* By having flexibility around how the
resource owner / End-User is referred to by the Authorization server (e.g
allow the identifier to be something like a public key or a resolvable
identifier to public keys such as a DID)

*Solving the NASCAR problem *- One of those enduring problems in identity
systems, which I think is really about the three way negotiation going on
between the RP, the End-User and the Provider. SIOP's solution pushed for
most of the power in this decision making process to lie with the End-User,
letting them decide who they want as their provider rather than RP's
providing an enumeration of who they support via provider icons on their
login page and End-Users having to select from those options. It
accomplished this via using a custom URL scheme of `openid://` where the
End-User would register their chosen provider as a protocol handler for the
`openid://` scheme. However, again as a solution it's not without it's
challenges, notably; only a single registration at a time can be supported,
the actual identity of the provider remains blind to the RP until after the
request is sent and it requires registration or some form of default
handling (e.g when there is no provider registered).

*How GNAP can solve for this?* I actually don't think this is core to GNAP,
there may be some considerations around discovery that are worth paying
attention to but not much in the core protocol design.

*Exploring different deployment models for the provider* - This is the most
frequently talked about aspect of SIOP and perhaps the most interesting to
GNAP. I like to think about the scope of this issue as designing to allow
for either a partially or fully distributed/decentralized provider, rather
than a centralized one (e.g an HTTP based AuthZ server). As you noted this
does come with its challenges many of which are technical in nature, i.e
how to appropriately address a decentralized provider and what protocols
are used to communicate with the provider.

*How GNAP can solve for this?* I think that's what much of the discussion
on this thread will be about and whether there is a hybrid model where some
responsibility is still centrally administered like token issuance, while
allowing other aspects to occur in a more distributed manner. Ideally
though I'd like to see consideration for a completely distributed model too.

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 Thu, Feb 18, 2021 at 9:19 PM Fabien Imbault <[email-masked]>
wrote:

>> With both of these, a key aspect remains: the AS needs to gather
>> necessary information, and issue the access token (or
>> identifiers/assertions). Because of how the protocol works, the client
>> software now has a better opportunity to present information to the AS,
>> either directly in the request or by introducing the AS to another software
>> component during the “interaction” phase. So, what if we think of the AS
>> primarily as a “token issuer”?
>>
>> Coming from the OAuth world, it feels weird to issue tokens like this,
>> but there’s precedent for this kind of thing. Today, a there are a number
>> of service-based OAuth AS's that are told what claims need to get put into
>> the access token by some trusted component. All of this happens outside the

-- 
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: Justin Richer <[email-masked]>
Date: Fri, 19 Feb 2021 14:30:05 -0500

Tobias, thanks for the great observations. Some reactions inline below.

> On Feb 18, 2021, at 7:59 PM, Tobias Looker <[email-masked]> wrote:
> 
> Justin,
> 
> I think this is a great and timely conversation to be having given the current interest around SSI and efforts like SIOP, I have been doing quite a bit of work in this space as of recent, so thought I'd add a few of the observations that I've made.
> 
> In my opinion SIOP was really a bucket for solving quite a few different problems, not just one. In particular I think its intent was to solve 3 major ones:
> 
> To drill down briefly on these, note much of my terminology is OpenID based due to SIOPs origin 
> 
> Enabling portable identities - In general today in the case of OpenID, the end-users identity as understood by a relying party is scoped within the domain of the provider. Which means if that provider goes out of business or for whatever reason decides to no longer offer the same identity services to the End-User, their identity is essentially gone. Whilst there has been some interesting related work from groups like MODRNA on solutions to combat this like 'Account Porting', they often assume the old provider remains online and willing to facilitate in the account porting process so that the End-User can migrate to a new provider. SIOP actually elected to do something different here by using cryptography, instead of the End-User identifier being something like a GUID asserted within the domain of the provider, SIOP defined this instead as a public key fingerprint associated to a private key that's assumed to be under the control of the user. In doing so the identity itself becomes portable between providers by transferring the associated private key. Now this approach does have drawbacks and arguably encourages what many would refer to as bad cryptographic practise by not allowing any way to do key rotation, however the idea was there. 
> 
> How GNAP can solve for this? By having flexibility around how the resource owner / End-User is referred to by the Authorization server (e.g allow the identifier to be something like a public key or a resolvable identifier to public keys such as a DID)

I personally think that GNAP should be a flexible :carrier: of identifiers and other bits of identity information. This is the main reason we went with the Subject Identifiers draft from SECEVENT: it’s set up to talk about a variety of different kinds of identifiers, all of them asserted in the context of the AS. If there’s a definition for a DID URL or a JWK in the sub_ids object structure, GNAP would be able to just use it directly alongside every other format. I haven’t seen those proposed yet, but it would be easy to do and, in my mind, would be a better solution than the portable identifiers proposal that was recently brought up in the FAPI working group in OIDF. (A side note, but the main problem I have here is that it’s pasting semantics and formats onto a field where none existed before, and that’s rife for problems. Better to have a structure that takes that into account from the start, in my view.)

> 
> Solving the NASCAR problem - One of those enduring problems in identity systems, which I think is really about the three way negotiation going on between the RP, the End-User and the Provider. SIOP's solution pushed for most of the power in this decision making process to lie with the End-User, letting them decide who they want as their provider rather than RP's providing an enumeration of who they support via provider icons on their login page and End-Users having to select from those options. It accomplished this via using a custom URL scheme of `openid://` where the End-User would register their chosen provider as a protocol handler for the `openid://` scheme. However, again as a solution it's not without it's challenges, notably; only a single registration at a time can be supported, the actual identity of the provider remains blind to the RP until after the request is sent and it requires registration or some form of default handling (e.g when there is no provider registered).
> 
> How GNAP can solve for this? I actually don't think this is core to GNAP, there may be some considerations around discovery that are worth paying attention to but not much in the core protocol design.
> 

SIOP doesn’t really solve the NASCAR issue since SIOP, by design, becomes yet one more login option among many. I think GNAP can help this by enabling user-directed provider discovery to kick off the process, but I agree that the core protocol doesn’t really have much to say here, and shouldn’t.

> Exploring different deployment models for the provider - This is the most frequently talked about aspect of SIOP and perhaps the most interesting to GNAP. I like to think about the scope of this issue as designing to allow for either a partially or fully distributed/decentralized provider, rather than a centralized one (e.g an HTTP based AuthZ server). As you noted this does come with its challenges many of which are technical in nature, i.e how to appropriately address a decentralized provider and what protocols are used to communicate with the provider. 
> 
> How GNAP can solve for this? I think that's what much of the discussion on this thread will be about and whether there is a hybrid model where some responsibility is still centrally administered like token issuance, while allowing other aspects to occur in a more distributed manner. Ideally though I'd like to see consideration for a completely distributed model too.

I agree that this seems to be the most interesting place for overlap. I don’t actually think the “hybrid” approach centralizes things. Instead, you can think of the RS as having an associated AS, and that AS accepting user consent and claims at runtime from a variety of sources (wallets, VCs, etc.). In this way, we aren’t talking about a single AS in the world handling all of these requests, we’re talking about a distributed network of AS’s associated with an even more widely distributed set of RS’s. SSI and its associated technologies would help these “local” AS’s issue access tokens without the RO needing to have an account, or even necessarily directly interacting with the AS. There’s currently a technology gap there, but my thoughts are that this is where the changes to the interaction modes section can really come to play. 

I think the notion of a non-HTTP AS is interesting, but I’m not sure if that’s something GNAP ought to be solving for. I think that there’s a deep value in building on top of HTTP for the core protocol, and not abstracting away concepts from it. Otherwise, you end up re-inventing layers, and you get something like SOAP all over again. :)

 — Justin

> 
> Thanks,
>  <https://mattr.global/>	 	
> Tobias Looker
> Mattr
> +64 (0) 27 378 0461
> [email-masked] <mailto:[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 Thu, Feb 18, 2021 at 9:19 PM Fabien Imbault <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Justin,
> 
> I agree that defining AS role primarily as a token issuer is a fruitful idea. Solving this problem well would also respond to the challenges discussed previously on the list. 
> 
> Cheers
> Fabien 
> 
> 
> Le mer. 17 févr. 2021 à 23:27, Justin Richer <[email-masked] <mailto:[email-masked]>> a écrit :
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
> -- 
> TXAuth mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/txauth <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: Adrian Gropper <[email-masked]>
Date: Fri, 19 Feb 2021 17:50:04 -0500

I agree with the first two of Justin's responses but not the last one.

It's confusing to think that there are more RS than AS. From a
human-centered (and hopefully IETF) perspective, each person might control
or specify a different AS for each of their personas or for each child or
incompetent delegate of them as guardian. We're familiar with separate
gmail addresses for each persona.

ASs will be self-sovereign (as in SSI), fiduciary (as in a custodial
bitcoin wallet), or brokers (as in data brokers and surveillance
capitalism). Any RS that is willing to have a recurring relationship with a
persona could accept a GNAP AS endpoint instead of an email address. This
is easiest using HTTP, but GNAP need not exclude other RS / AS APIs and
transports. Designing around the uncensored specification of one's AS as a
human right would greatly simplify many aspects of GNAP adoption.

That said, GNAP should not ignore the RS business or jurisdictional reasons
to limit the authority of the AS. UMA 2.0 spent years dancing around this
issue with ideas like "cascading" AS and various centralized or federated
AS concepts. My conclusion is that any RS can always do whatever it wants
and there's not much the authorization protocol can help with other than
specifying a notification endpoint so that an RS can warn (and seek
confirmation) or log various exceptions. This turns out to be, after a year
of testimony, the regulation that applies to HIPAA RS APIs in the US. For
this reason GNAP might include a notification protocol in the AS
specification, or not.

I propose that embracing a self-sovereign agent is key to harmonizing the
SSI and GNAP standards.

Adrian

On Fri, Feb 19, 2021 at 2:30 PM Justin Richer <[email-masked]> wrote:

> I personally think that GNAP should be a flexible :carrier: of identifiers
> and other bits of identity information. This is the main reason we went
> with the Subject Identifiers draft from SECEVENT: it’s set up to talk about
> a variety of different kinds of identifiers, all of them asserted in the
> context of the AS. If there’s a definition for a DID URL or a JWK in the
> sub_ids object structure, GNAP would be able to just use it directly
> alongside every other format. I haven’t seen those proposed yet, but it
> would be easy to do and, in my mind, would be a better solution than the
> portable identifiers proposal that was recently brought up in the FAPI
> working group in OIDF. (A side note, but the main problem I have here is
> that it’s pasting semantics and formats onto a field where none existed
> before, and that’s rife for problems. Better to have a structure that takes
> that into account from the start, in my view.)
>
>
> *How GNAP can solve for this?* I actually don't think this is core to
> GNAP, there may be some considerations around discovery that are worth
> paying attention to but not much in the core protocol design.
>
>
> SIOP doesn’t really solve the NASCAR issue since SIOP, by design, becomes
> yet one more login option among many. I think GNAP can help this by
> enabling user-directed provider discovery to kick off the process, but I
> agree that the core protocol doesn’t really have much to say here, and
> shouldn’t.
>
> *Exploring different deployment models for the provider* - This is the
> most frequently talked about aspect of SIOP and perhaps the most
> interesting to GNAP. I like to think about the scope of this issue as
> designing to allow for either a partially or fully
> distributed/decentralized provider, rather than a centralized one (e.g an
> HTTP based AuthZ server). As you noted this does come with its challenges
> many of which are technical in nature, i.e how to appropriately address a
> decentralized provider and what protocols are used to communicate with the
> provider.
>
> I agree that this seems to be the most interesting place for overlap. I
> don’t actually think the “hybrid” approach centralizes things. Instead, you
> can think of the RS as having an associated AS, and that AS accepting user
> consent and claims at runtime from a variety of sources (wallets, VCs,
> etc.). In this way, we aren’t talking about a single AS in the world
> handling all of these requests, we’re talking about a distributed network
> of AS’s associated with an even more widely distributed set of RS’s. SSI
> and its associated technologies would help these “local” AS’s issue access
> tokens without the RO needing to have an account, or even necessarily
> directly interacting with the AS. There’s currently a technology gap there,
> but my thoughts are that this is where the changes to the interaction modes
> section can really come to play.
>
> I think the notion of a non-HTTP AS is interesting, but I’m not sure if
> that’s something GNAP ought to be solving for. I think that there’s a deep
> value in building on top of HTTP for the core protocol, and not abstracting
> away concepts from it. Otherwise, you end up re-inventing layers, and you
> get something like SOAP all over again. :)
>
>  — Justin
>
>
> Thanks,
>  <https://mattr.global/>
> *Tobias Looker*
> Mattr
> +64 (0) 27 378 0461
>>> The last interim call had a lot of discussion on SSI technologies such
>>> as digital wallets, and how those fit with GNAP. I think it’s worth
>>> continuing that conversation here on the list. There are a few issues in
>>> the tracker that give some background, too:
>>>

---

From: Fabien Imbault <[email-masked]>
Date: Sat, 20 Feb 2021 03:03:28 +0100

Hi Adrian,

"It's confusing to think that there are more RS than AS" frames the problem
we're dealing with.
I think it really depends on how we view the auth world today and in the
future.

Today there are many RSs providing specialized APIs. Openbanking is an
obvious example. So we're speaking the order of magnitude of the number of
organizational units for RSs, versus a few centralized IdPs and ASs.
Notice that if we can design GNAP in a  more modular fashion than OAuth2 by
enabling multiple ASs, that would already be a fairly effective way to
decentralize authorizations. Orgs are a well known target for privacy
regulations, so we know what to expect, even if that's imperfect (of course
bigtech regulation is still largely an unsolved problem, but laws are
gradually evolving).

Now there's another view, which is : each person should be operating its
own AS and have its own wallet, as everyone has a phone.
While I believe P. Sheldrake offers a few hints of why we should reflect on
the social/ethical consequences of the technology (the generative vs
self-sovereign identity debate, which I tried to summarize at
https://fimbault.medium.com/the-ethical-dilemma-posed-by-decentralized-identity-f8328b655544),
it's quite clear that it is yet a prospective view. Wallets will need to be
"crossing the chiasm".

To ensure user privacy, what's the best path between an approach focused on
orgs and self sovereignty (or whatever else we call the approach)? We might
have preferences, but in practice it's hard to know what will happen and we
might end-up with a mix of the 2, depending on the use case.
Being fairly agnostic is really what GNAP can help with, and I think
positioning the AS primarily as a "token issuer" enables that flexibility,
all the more valuable in the face of uncertainty.

There's also a technological readiness level to consider. We have years of
experience with HTTP, we know how it can be used for our use case. We know
its limitations. We know its future (HTTP/3). Which makes it a good
candidate for an industrial standard.

Building a fully decentralized alternative is anything but trivial. I'm not
sure we should target fixing the web thanks to GNAP, an "hybrid" approach
to decentralization (enabling communication with wallets) might be more
realistic and focused.

Whatever we choose, the goal I think is to clarify the expectations, and be
open to work and align with other initiatives.

Cheers
Fabien

Le ven. 19 févr. 2021 à 23:50, Adrian Gropper <[email-masked]> a
écrit :

> That said, GNAP should not ignore the RS business or
> jurisdictional reasons to limit the authority of the AS. UMA 2.0 spent
> years dancing around this issue with ideas like "cascading" AS and various
> centralized or federated AS concepts. My conclusion is that any RS can
> always do whatever it wants and there's not much the authorization protocol
> can help with other than specifying a notification endpoint so that an RS
> can warn (and seek confirmation) or log various exceptions. This turns out
> to be, after a year of testimony, the regulation that applies to HIPAA RS
> APIs in the US. For this reason GNAP might include a notification protocol
> in the AS specification, or not.
>
>> I personally think that GNAP should be a flexible :carrier: of
>> identifiers and other bits of identity information. This is the main reason
>> we went with the Subject Identifiers draft from SECEVENT: it’s set up to
>> talk about a variety of different kinds of identifiers, all of them
>> asserted in the context of the AS. If there’s a definition for a DID URL or
>> a JWK in the sub_ids object structure, GNAP would be able to just use it
>> directly alongside every other format. I haven’t seen those proposed yet,
>> but it would be easy to do and, in my mind, would be a better solution than
>> the portable identifiers proposal that was recently brought up in the FAPI
>> *Solving the NASCAR problem *- One of those enduring problems in
>> identity systems, which I think is really about the three way negotiation
>> going on between the RP, the End-User and the Provider. SIOP's solution
>> pushed for most of the power in this decision making process to lie with
>> the End-User, letting them decide who they want as their provider rather
>> than RP's providing an enumeration of who they support via provider icons
>> on their login page and End-Users having to select from those options. It
>> *How GNAP can solve for this?* I think that's what much of the
>> discussion on this thread will be about and whether there is a hybrid model
>> where some responsibility is still centrally administered like token
>> issuance, while allowing other aspects to occur in a more distributed
>> manner. Ideally though I'd like to see consideration for a completely
>> distributed model too.
>>
>>
>> This communication, including any attachments, is confidential. If you
>> are not the intended recipient, you should not read it - please contact me
>>>> There’s been a lot of interesting work recently in the OpenID
>>>> Foundation around using the Self-issued OP (SIOP) functionality to
>>>> bootstrap an SSI style login. This makes extensive use of the implicit flow
>>>> and front channel messaging, but minimization of the front channel for
>>>> message passing is a key design tenet of GNAP (so much so that it’s
>>>> included in our charter). Instead, GNAP has been built around an idea that
>>>> everything starts the same way: with an HTTP request to the AS.
>>>>
>>>> For example, if the client can present a verifiable credential (VC)
>>>> that represents the end user, the AS can validate that VC and make an
>>>> access token on behalf of that user, without having the user log in or
>>>> interact with the AS at all. This VC can contain whatever access rights the
>>>> token needs to represent, and the AS can translate that into an artifact
>>>> that the downstream RS’s can interpret, without having to see the original
>>>> VC or the user at all. The AS is still HTTP based, but all the essential
>>>> security and rights elements are provided by the wallet. In this way, we
>>>> can expand on the privacy-preserving aspects of OAuth and bridge the worlds
>>>> of SSI and web APIs without violating the basic nature of either.
>>>>

---

From: Adrian Gropper <[email-masked]>
Date: Fri, 19 Feb 2021 23:19:57 -0500

Hi Fabien,

I don't disagree with the idea that GNAP should not presume the adoption of
SSI standards or philosophy. (P. Sheldrake and I are pals and I'm an
informal channel between EFF and some SSI workgroups.)

I do believe that RS and data brokers have a growing security problem that
only Zero-Trust Architecture can do much to solve. Mobile wallets are
essential to provide the non repudiable signatures (regardless of how
credentials are managed for privacy) and this will tend to facilitate some
decentralization even if it would not come naturally to the RS enterprise.
The SSI standards will apply to growing ZTA.

ZTA cannot work just between wallet and RS. It needs delegation,
notarization, and audit. Therefore, I see GNAP as playing the central role.

>From this ZTA perspective, rather than privacy or decentralization as an
abstract goal, the question of whether there are more or fewer ASs than
wallets is arguable. One guardian on the RO side or one "associate" on the
RS side could easily each have as many AS as they have wallets. Their ASs
represent personas and semi-autonomous agents. Their multiple wallets
represent redundant user agent devices each with a separate biometrically
locked HSM.

In an enterprise (RS or data broker) ZTA system, the delegation target may
tend to look more like an agent (AS) or client (RC)  than like a wallet.
For example, in healthcare the guardians and associates control wallets and
AS agents as the target of delegation (workflow) while the enterprise
electronic health record looks more like a client to various RSs. With ZTA,
the RSs will be both in and out of the control of the enterprise. I've
summarized the relationship between wallets, AS, RC, and RS as 6 use-cases
in this short set of slides:
https://docs.google.com/presentation/d/1ksKal62ZiApX09Nejm4RSqHzHJbgwpu_l2Ho64_ePKU/edit#slide=id.gb2d2b0f28a_0_0

I hope this clarifies some expectations and where GNAP needs to align with
other initiatives.

Adrian

On Fri, Feb 19, 2021 at 9:03 PM Fabien Imbault <[email-masked]>
wrote:

> Hi Adrian,
>
> "It's confusing to think that there are more RS than AS" frames the
> problem we're dealing with.
> Notice that if we can design GNAP in a  more modular fashion than OAuth2
> by enabling multiple ASs, that would already be a fairly effective way to
> While I believe P. Sheldrake offers a few hints of why we should reflect
> on the social/ethical consequences of the technology (the generative vs
> To ensure user privacy, what's the best path between an approach focused
> on orgs and self sovereignty (or whatever else we call the approach)? We
> might have preferences, but in practice it's hard to know what will happen
> and we might end-up with a mix of the 2, depending on the use case.
> Building a fully decentralized alternative is anything but trivial. I'm
> not sure we should target fixing the web thanks to GNAP, an "hybrid"
> approach to decentralization (enabling communication with wallets) might be
> more realistic and focused.
>
> Whatever we choose, the goal I think is to clarify the expectations, and
> be open to work and align with other initiatives.
>
> Cheers
> Fabien
>
>
>>> *Enabling portable identities *- In general today in the case of
>>> OpenID, the end-users identity as understood by a relying party is scoped
>>> within the domain of the provider. Which means if that provider goes out of
>>> accomplished this via using a custom URL scheme of `openid://` where
>>> the End-User would register their chosen provider as a protocol handler for
>>> the `openid://` scheme. However, again as a solution it's not without
>>> it's challenges, notably; only a single registration at a time can be
>>> supported, the actual identity of the provider remains blind to the RP
>>> until after the request is sent and it requires registration or some form
>>> of default handling (e.g when there is no provider registered).
>>>
>>> SIOP doesn’t really solve the NASCAR issue since SIOP, by design,
>>> becomes yet one more login option among many. I think GNAP can help this by
>>>  <https://mattr.global/> [image: Mattr on
>>> LinkedIn] <https://www.linkedin.com/company/mattrglobal> [image: Mattr
>>> on Twitter] <https://twitter.com/mattrglobal>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 21 Feb 2021 10:34:16 +0100

> Am 19.02.2021 um 23:50 schrieb Adrian Gropper <[email-masked]>:
> 
> 
> It's confusing to think that there are more RS than AS.

the OAuth deployments I‘m aware of typically have much more RSs than ASs. Why? Because AS and a set of RSs belong to the same security domain (e.g. a certain business) and it’s the AS’s responsibility to ensure secure and convenient access to the APIs provided by this RSs. For example: there is a AS controlling access to a cloud, streaming, and messaging services of the same business. In case of open banking, the bank‘s AS is (on behalf of the user) authorizing access to APIs for account information as well as payment initiation and potentially other services. 

Technically, the respective AS and RSs set up a trust relationship and agreed on ways to share authorization and user data in order enable secure API access.

I read your ideas regarding self-sovereign ASs with great interest and got some observations/questions:
- A personal AS could certainly control access to a person‘s resources. I assume the person‘s RSs would only accept access tokens signed by the RO. Am I right?
- Do you envision this AS to be able to control access to any kind of RS? How is the AS supposed to know what authorization data this RS needs in order to perform access control decisions? What data will be exchanged?
- How would this person delegate access to her resources to someone else?
- Are you aware of deployments implementing this philosophy?
- What are the implications in terms of user experience?

In my experience coupling between AS and RS is very tight. I have a hard time to see how self-sovereign ASs would work. It feels like such an AS in the end is an identity provider of some sort, which brings me to what Justin proposed. I would assume using SSI credentials to authenticate towards ASs is feasible and might have value but I‘m skeptical about the AS part.

best regards,
Torsten.

> From a human-centered (and hopefully IETF) perspective, each person might control or specify a different AS for each of their personas or for each child or incompetent delegate of them as guardian. We're familiar with separate gmail addresses for each persona.
> 
> ASs will be self-sovereign (as in SSI), fiduciary (as in a custodial bitcoin wallet), or brokers (as in data brokers and surveillance capitalism). Any RS that is willing to have a recurring relationship with a persona could accept a GNAP AS endpoint instead of an email address. This is easiest using HTTP, but GNAP need not exclude other RS / AS APIs and transports. Designing around the uncensored specification of one's AS as a human right would greatly simplify many aspects of GNAP adoption.
> 
> That said, GNAP should not ignore the RS business or jurisdictional reasons to limit the authority of the AS. UMA 2.0 spent years dancing around this issue with ideas like "cascading" AS and various centralized or federated AS concepts. My conclusion is that any RS can always do whatever it wants and there's not much the authorization protocol can help with other than specifying a notification endpoint so that an RS can warn (and seek confirmation) or log various exceptions. This turns out to be, after a year of testimony, the regulation that applies to HIPAA RS APIs in the US. For this reason GNAP might include a notification protocol in the AS specification, or not.
> 
> I propose that embracing a self-sovereign agent is key to harmonizing the SSI and GNAP standards.
> 
> Adrian
> 
>>>> On Thu, Feb 18, 2021 at 9:19 PM Fabien Imbault <[email-masked]> wrote:
>>>> Hi Justin,
>>>> 
> https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/txauth&source=gmail-imap&ust=1614379828000000&usg=AOvVaw3avsUGQ48fo1OUQV0vyyKd

---

From: Adrian Gropper <[email-masked]>
Date: Sun, 21 Feb 2021 09:40:39 -0500

Hi Torsten,

Thank you for raising all of these excellent points. I hope we can all
answer them and maybe even add a section to the wiki. I'll start...

You're right that OAuth deployments almost exclusively put the AS and RS in
the same domain. If OAuth were adequate to today's needs we probably would
not be here doing GNAP. Since OAuth, we have increasing privacy concerns
and security disasters. GDPR, for example, separates the role of a data
controller from a data processor and treats them as separate legal
entities. To oversimplify GDPR, the data processor is spared privacy
responsibility and cost.

You are also right to mention open banking as a use-case. Open banking has
not adopted UMA 2.0 (on which I have worked for almost a decade) which is
based on OAuth. PSD2 and similar regulations do not tie the AS and RS to
the same security domain but they presume a narrow federation of licensed
(and regulated) ASs as payment processors for subjects to choose among.
This centralization to regulated fiduciaries is a privacy trade-off that
makes sense in banking. The fiduciary can be bonded so they can refund the
money to the subject in case of a security breach. This privacy-security
tradeoff does not make sense in healthcare and other domains where the
consequences of a breach are not easily reversed.

This thread is about aligning GNAP and SSI. SSI does not abide
centralization, censorship, or surveillance. If GNAP makes any assumptions
that result in either a tight coupling between AS and RS (surveillance) or
even a federated fiduciary (centralization) we will lose out on the
benefits of progress in digital identity that is now driving a lot of
public-sector initiatives and starting to bleed over into private sector
practices. Zero Trust Architecture is an example and OAuth is not well
suited for ZTA.

As you said, "technically, the respective AS and RSs set up a trust
relationship and agreed on ways to share authorization and user data in
order [to] enable secure API access." This is where GNAP operates and we
need to avoid _any_ restrictions on either the AS or the RS being
self-sovereign. Examples of a self-sovereign RS could be a personal data
store or an encrypted data vault like the ones we work on in W3C/DIF. Any
AS can be self-sovereign if the subject controls all of the policies and
these policies are not shared, in the same way a private key is never not
shared.

Continuing your quote:

> - A personal AS could certainly control access to a person‘s resources. I
> assume the person‘s RSs would only accept access tokens signed by the RO.
> Am I right?
>
Yes, and. There is debate in various SSI WGs whether a RS such as an
Encrypted Data Vault should respond to capabilities or tokens. Either way,
the RO is in control of the signature but a personal AS is a delegate of
the RO (either directly or via a mobile user agent). With capabilities such
as ZCAP-LD or biscuits, the token signature allows for filtered delegation.

- Do you envision this AS to be able to control access to any kind of RS?
> How is the AS supposed to know what authorization data this RS needs in
> order to perform access control decisions? What data will be exchanged?
>
Yes. The whole point, as far as I'm concerned, is to design human centered
standards. This is how W3C and IETF are different. Other SDOs tend to be
operated for institutional benefit. A person-centered AS must work across
institutional domains.

This, as you point out, brings up the problem of scope. Ontologies and data
models are, justifiably, domain-specific. I, for example, work around the
HL7 data model standards and APIs like FHIR that are controlled by
healthcare business interests. It's unreasonable to expect a general
solution to the data model problem, although folks of the Linked Data
persuasion might disagree.

Every RS gets to decide what data models and ontologies it supports. These
decisions are public and sometimes standardized for the benefit of the
clients. A person's AS must read and maybe understand the RS data model in
order to issue tokens just like the client needs to do in order to make a
request to the AS. In our HIE of One Trustee project, we allow the
self-sovereign subject to inherit AS policies from self-sovereign
communities they choose and then modify the policies if they want. In this
way, communities compete for members on the basis of policy bundles the
same way churches compete for congregants.

There are two "persons" to consider. The RO delegates to an RQ. But the RQ,
in real life, is part of a team and often delegates to associates. With or
without capabilities, GNAP needs to deal with this reality that RO and RQ
user agents may be different from the client that actually presents a token
to the RS. Some of this difference between user agents and clients we may
be able to keep out of band.

Other than our HIE of One demonstration project in healthcare, no. We
started HIE of One before SSI in order to drive the transition from UMA to
UMA 2.0 and inform various healthcare regulatory priorities. We then jumped
on SSI immediately and added it to the UMA 2 AS we call Trustee. Now we are
trying to align SSI and GNAP in order to enable human-centered protocols
and zero-trust architecture.

> - What are the implications in terms of user experience?

Right now, the human-centered user experience assumes a secure element and
web browser as user agents on a mobile device. Neither of these is readily
accessible as a server nor are they designed to accept code plug-ins that
represent the policies of an AS. One major exception is people adding
advertising and surveillance blockers like EFF Privacy Badger to their
browser.

The user experience implications of having SSI data model standards and
GNAP protocol standards is that today's password managers (I have 250 RS
relationships in mine) will evolve to also control an AS agent. Just like I
might register a W3C DID with an RS instead of an email address, my policy
manager might display to me the token policies that will be applied by my
AS to the personal data I can control at that RS.

In some cases, my AS will allow me to modify those policies just like the
obnoxious cookie policy settings do today. The BIG difference with GNAP is
that I choose my AS separately from the RS so the dark patterns associated
with today's cookie policies experience are no longer possible. GNAP means
the RS exposes an API rather than a UI.

I've gone on far too long to address the issue of the AS as an identity
provider. It's fair to think of it that way. As it turns out, in the SSI
Secure Data Storage WG, we are debating the difference between an Encrypted
Data Vault and an Identity Hub. As far as I'm concerned, the Identity Hub
is mostly a GNAP AS. Join us on Thursdays at 4 PM ET
https://lists.identity.foundation/g/sds-wg/wiki/Home

Adrian

On Sun, Feb 21, 2021 at 4:34 AM Torsten Lodderstedt <[email-masked]>
wrote:

> the OAuth deployments I‘m aware of typically have much more RSs than ASs.
> Why? Because AS and a set of RSs belong to the same security domain (e.g. a
> certain business) and it’s the AS’s responsibility to ensure secure and
> convenient access to the APIs provided by this RSs. For example: there is a
> AS controlling access to a cloud, streaming, and messaging services of the
> same business. In case of open banking, the bank‘s AS is (on behalf of the
> user) authorizing access to APIs for account information as well as payment
> initiation and potentially other services.
>
> Technically, the respective AS and RSs set up a trust relationship and
> agreed on ways to share authorization and user data in order enable secure
> API access.
>
> - A personal AS could certainly control access to a person‘s resources. I
> assume the person‘s RSs would only accept access tokens signed by the RO.
> Am I right?
> - Do you envision this AS to be able to control access to any kind of RS?
> How is the AS supposed to know what authorization data this RS needs in
> order to perform access control decisions? What data will be exchanged?
> In my experience coupling between AS and RS is very tight. I have a hard
> time to see how self-sovereign ASs would work. It feels like such an AS in
> the end is an identity provider of some sort, which brings me to what
> Justin proposed. I would assume using SSI credentials to authenticate
> towards ASs is feasible and might have value but I‘m skeptical about the AS
> part.
>
> best regards,
> Torsten.
>
> From a human-centered (and hopefully IETF) perspective, each person might
> control or specify a different AS for each of their personas or for each
> child or incompetent delegate of them as guardian. We're familiar with
> separate gmail addresses for each persona.
>
>> <https://www.google.com/url?q=https://mattr.global/&source=gmail-imap&ust=1614379828000000&usg=AOvVaw2w9AL-TL2QlHO6RwxqWQyZ>
>>
>> *Tobias Looker*
>> Mattr
>> +64 (0) 27 378 0461
>> <https://www.google.com/url?q=https://mattr.global/&source=gmail-imap&ust=1614379828000000&usg=AOvVaw2w9AL-TL2QlHO6RwxqWQyZ> [image:
>> Mattr on LinkedIn]
>> <https://www.google.com/url?q=https://www.linkedin.com/company/mattrglobal&source=gmail-imap&ust=1614379828000000&usg=AOvVaw3lMMq8NBc2SQydPN2L456A> [image:
>> Mattr on Twitter]
>> <https://www.google.com/url?q=https://twitter.com/mattrglobal&source=gmail-imap&ust=1614379828000000&usg=AOvVaw0zeSL9sn_ak-UOBMq0yPqv> [image:
>> Mattr on Github]
>> <https://www.google.com/url?q=https://github.com/mattrglobal&source=gmail-imap&ust=1614379828000000&usg=AOvVaw2D-EXKiFVwiOXynoCnYOVQ>
>>>> <https://www.google.com/url?q=https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/175&source=gmail-imap&ust=1614379828000000&usg=AOvVaw1qnd2F79zmQk_LGtaysKeP>
>>>>
>>>> <https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/txauth&source=gmail-imap&ust=1614379828000000&usg=AOvVaw3avsUGQ48fo1OUQV0vyyKd>
>>>>
>>> --
>>> TXAuth mailing list
>>> [email-masked]
>>> <https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/txauth&source=gmail-imap&ust=1614379828000000&usg=AOvVaw3avsUGQ48fo1OUQV0vyyKd>
>>>
>>
>> <https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/txauth&source=gmail-imap&ust=1614379828000000&usg=AOvVaw3avsUGQ48fo1OUQV0vyyKd>
>>
> --
> TXAuth mailing list
> [email-masked]
>

---

From: Justin Richer <[email-masked]>
Date: Mon, 22 Feb 2021 13:40:23 -0500

An important aspect in the discussion here, that I agree with, is that the RS needs to be able to decide which AS it talks to. But inherent in that is that it’s not the user’s decision, or the AS’s decision, it’s the RS’s decision who it will trust to get tokens from. And no matter what our philosophy, at the end of the day the RS will always have the choice of whether to trust an inbound request.

Which is why, to me, this really brings us to the question of what an AS provides. The AS gives the RS a token that the RS decides to trust, and that the RS can understand (either directly with something like JWT or indirectly with something like introspection). But the AS also needs to decide what to put INTO that token. As a consequence, the AS can get that information from any number of places. The information could be provided in a trusted way by the end user to the AS — but this does NOT necessarily mean that the AS belongs to the user or is under their control. 

Basically, I think we’re trying to hard to map the OAuth general-concept of the RO having an account at the AS and logging in to it before authorizing the request. I think that the call for “every user to have their own AS” is such a huge non-starter in so many domains that it hampers the solution space if that’s what we presume. It’s up to the RS to decide who it trusts, not the end user and not the RO. 

I think we should ALLOW it, and we can be clearer in GNAP that that’s one possible model, but not the only one, and not even the general one. The AS manages all of the information and interconnections needed to create an access token that the RS will accept, and it is in charge of signaling to the RS what that token’s good for. However, if the AS can learn through some other means that a specific identified user has consented and provided appropriate information in a trusted way, then THAT information can be baked into the token by the AS. — importantly, in a way that the RS’s the AS protects can understand. 

This last bit is where general opacity of tokens is important here. There’s a natural security boundary that arises from this model. What I’m proposing here is just that we’re more explicit about what can be put INTO that boundary. That’s where I’m seeing a lot of this innovation in the SSI space fitting. You’re not coming up with some universal access token that the RS will accept, but you’re able to provide universal claims and artifacts that an AS can process and translate into a token the RS will accept and do the right thing with.

 — Justin

> On Feb 21, 2021, at 9:40 AM, Adrian Gropper <[email-masked]> wrote:
> 
> Hi Torsten,
> 
> Thank you for raising all of these excellent points. I hope we can all answer them and maybe even add a section to the wiki. I'll start...
> 
> You're right that OAuth deployments almost exclusively put the AS and RS in the same domain. If OAuth were adequate to today's needs we probably would not be here doing GNAP. Since OAuth, we have increasing privacy concerns and security disasters. GDPR, for example, separates the role of a data controller from a data processor and treats them as separate legal entities. To oversimplify GDPR, the data processor is spared privacy responsibility and cost.
> 
> You are also right to mention open banking as a use-case. Open banking has not adopted UMA 2.0 (on which I have worked for almost a decade) which is based on OAuth. PSD2 and similar regulations do not tie the AS and RS to the same security domain but they presume a narrow federation of licensed (and regulated) ASs as payment processors for subjects to choose among. This centralization to regulated fiduciaries is a privacy trade-off that makes sense in banking. The fiduciary can be bonded so they can refund the money to the subject in case of a security breach. This privacy-security tradeoff does not make sense in healthcare and other domains where the consequences of a breach are not easily reversed.
> 
> This thread is about aligning GNAP and SSI. SSI does not abide centralization, censorship, or surveillance. If GNAP makes any assumptions that result in either a tight coupling between AS and RS (surveillance) or even a federated fiduciary (centralization) we will lose out on the benefits of progress in digital identity that is now driving a lot of public-sector initiatives and starting to bleed over into private sector practices. Zero Trust Architecture is an example and OAuth is not well suited for ZTA.
> 
> As you said, "technically, the respective AS and RSs set up a trust relationship and agreed on ways to share authorization and user data in order [to] enable secure API access." This is where GNAP operates and we need to avoid _any_ restrictions on either the AS or the RS being self-sovereign. Examples of a self-sovereign RS could be a personal data store or an encrypted data vault like the ones we work on in W3C/DIF. Any AS can be self-sovereign if the subject controls all of the policies and these policies are not shared, in the same way a private key is never not shared. 
> 
> Continuing your quote:
> Yes, and. There is debate in various SSI WGs whether a RS such as an Encrypted Data Vault should respond to capabilities or tokens. Either way, the RO is in control of the signature but a personal AS is a delegate of the RO (either directly or via a mobile user agent). With capabilities such as ZCAP-LD or biscuits, the token signature allows for filtered delegation.
> 
> Yes. The whole point, as far as I'm concerned, is to design human centered standards. This is how W3C and IETF are different. Other SDOs tend to be operated for institutional benefit. A person-centered AS must work across institutional domains. 
> 
> This, as you point out, brings up the problem of scope. Ontologies and data models are, justifiably, domain-specific. I, for example, work around the HL7 data model standards and APIs like FHIR that are controlled by healthcare business interests. It's unreasonable to expect a general solution to the data model problem, although folks of the Linked Data persuasion might disagree.
> 
> Every RS gets to decide what data models and ontologies it supports. These decisions are public and sometimes standardized for the benefit of the clients. A person's AS must read and maybe understand the RS data model in order to issue tokens just like the client needs to do in order to make a request to the AS. In our HIE of One Trustee project, we allow the self-sovereign subject to inherit AS policies from self-sovereign communities they choose and then modify the policies if they want. In this way, communities compete for members on the basis of policy bundles the same way churches compete for congregants.
> 
> There are two "persons" to consider. The RO delegates to an RQ. But the RQ, in real life, is part of a team and often delegates to associates. With or without capabilities, GNAP needs to deal with this reality that RO and RQ user agents may be different from the client that actually presents a token to the RS. Some of this difference between user agents and clients we may be able to keep out of band.
> 
> Other than our HIE of One demonstration project in healthcare, no. We started HIE of One before SSI in order to drive the transition from UMA to UMA 2.0 and inform various healthcare regulatory priorities. We then jumped on SSI immediately and added it to the UMA 2 AS we call Trustee. Now we are trying to align SSI and GNAP in order to enable human-centered protocols and zero-trust architecture. 
>  
> Right now, the human-centered user experience assumes a secure element and web browser as user agents on a mobile device. Neither of these is readily accessible as a server nor are they designed to accept code plug-ins that represent the policies of an AS. One major exception is people adding advertising and surveillance blockers like EFF Privacy Badger to their browser. 
> 
> The user experience implications of having SSI data model standards and GNAP protocol standards is that today's password managers (I have 250 RS relationships in mine) will evolve to also control an AS agent. Just like I might register a W3C DID with an RS instead of an email address, my policy manager might display to me the token policies that will be applied by my AS to the personal data I can control at that RS. 
> 
> In some cases, my AS will allow me to modify those policies just like the obnoxious cookie policy settings do today. The BIG difference with GNAP is that I choose my AS separately from the RS so the dark patterns associated with today's cookie policies experience are no longer possible. GNAP means the RS exposes an API rather than a UI.
> 
> I've gone on far too long to address the issue of the AS as an identity provider. It's fair to think of it that way. As it turns out, in the SSI Secure Data Storage WG, we are debating the difference between an Encrypted Data Vault and an Identity Hub. As far as I'm concerned, the Identity Hub is mostly a GNAP AS. Join us on Thursdays at 4 PM ET https://lists.identity.foundation/g/sds-wg/wiki/Home <https://lists.identity.foundation/g/sds-wg/wiki/Home> 
> 
> Adrian
> 
> 
> 
> On Sun, Feb 21, 2021 at 4:34 AM Torsten Lodderstedt <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> Am 19.02.2021 um 23:50 schrieb Adrian Gropper <[email-masked] <mailto:[email-masked]>>:
>> 
>> 
>> On Fri, Feb 19, 2021 at 2:30 PM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>>> On Feb 18, 2021, at 7:59 PM, Tobias Looker <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Justin,
>>> 
>>> Solving the NASCAR problem - One of those enduring problems in identity systems, which I think is really about the three way negotiation going on between the RP, the End-User and the Provider. SIOP's solution pushed for most of the power in this decision making process to lie with the End-User, letting them decide who they want as their provider rather than RP's providing an enumeration of who they support via provider icons on their login page and End-Users having to select from those options. It accomplished this via using a custom URL scheme of `openid://` <> where the End-User would register their chosen provider as a protocol handler for the `openid://` <> scheme. However, again as a solution it's not without it's challenges, notably; only a single registration at a time can be supported, the actual identity of the provider remains blind to the RP until after the request is sent and it requires registration or some form of default handling (e.g when there is no provider registered).
>>> 
>>>  <https://www.google.com/url?q=https://mattr.global/&source=gmail-imap&ust=1614379828000000&usg=AOvVaw2w9AL-TL2QlHO6RwxqWQyZ>	 <https://www.google.com/url?q=https://www.linkedin.com/company/mattrglobal&source=gmail-imap&ust=1614379828000000&usg=AOvVaw3lMMq8NBc2SQydPN2L456A>	 <https://www.google.com/url?q=https://twitter.com/mattrglobal&source=gmail-imap&ust=1614379828000000&usg=AOvVaw0zeSL9sn_ak-UOBMq0yPqv>	 <https://www.google.com/url?q=https://github.com/mattrglobal&source=gmail-imap&ust=1614379828000000&usg=AOvVaw2D-EXKiFVwiOXynoCnYOVQ>
>>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/175 <https://www.google.com/url?q=https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/175&source=gmail-imap&ust=1614379828000000&usg=AOvVaw1qnd2F79zmQk_LGtaysKeP>
>>> 
>>> https://www.ietf.org/mailman/listinfo/txauth <https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/txauth&source=gmail-imap&ust=1614379828000000&usg=AOvVaw3avsUGQ48fo1OUQV0vyyKd>
>>> -- 
>>> TXAuth mailing list
>>> https://www.ietf.org/mailman/listinfo/txauth <https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/txauth&source=gmail-imap&ust=1614379828000000&usg=AOvVaw3avsUGQ48fo1OUQV0vyyKd>
>>> 
>> https://www.ietf.org/mailman/listinfo/txauth <https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/txauth&source=gmail-imap&ust=1614379828000000&usg=AOvVaw3avsUGQ48fo1OUQV0vyyKd>
>> -- 
>> TXAuth mailing list
>> https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/txauth&source=gmail-imap&ust=1614379828000000&usg=AOvVaw3avsUGQ48fo1OUQV0vyyKd <https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/txauth&source=gmail-imap&ust=1614379828000000&usg=AOvVaw3avsUGQ48fo1OUQV0vyyKd>

---

From: Denis <[email-masked]>
Date: Tue, 23 Feb 2021 13:51:14 +0100

Hi  Justin,

See my comments between the lines.
> An important aspect in the discussion here, that I agree with, is that 
> the RS needs to be able to decide _/which AS it talks to/_. 

  While I would agree with such a sentence in the OAuth WG, I don't 
believe that this sentence is applicable in general in the context of GNAP.
A RS does not need to "talk to" any AS. A RS decides which AS(s) it 
trusts to issue access tokens *that contains some set of privileges*.

> But inherent in that is that it’s not the user’s decision, or the AS’s 
> decision, it’s the RS’s decision who it will trust to get tokens from.

A RS does not necessarily need to trust all the access tokens issued by 
a given AS, but only access tokens from a given AS that contain
*a given set of privileges*.

> And no matter what our philosophy, at the end of the day the RS will 
> always have the choice of whether to trust an inbound request.

Not exactly: the RS will apply the rules given by the RO.

> Which is why, to me, this really brings us to the question of what an 
> AS provides. The AS gives the RS a token that the RS decides to trust,
> and that the RS can understand (either directly with something like 
> JWT or indirectly with something like introspection).
> But the AS also needs to decide what to put INTO that token. As a 
> consequence, the AS can get that information from any number of places.
> The information could be provided in a trusted way by the end user to 
> the AS — but this does NOT necessarily mean that the AS belongs
> to the user or is under their control.
>
> Basically, I think we’re trying to hard to map the OAuth 
> general-concept of the RO having an account at the AS and logging in 
> to it before authorizing the request.
> I think that the call for “every user to have their own AS” is such a 
> huge non-starter in so many domains that it hampers the solution space 
> if that’s what we presume.
> It’s up to the RS to decide who it trusts, not the end user and not 
> the RO.
>
> I think we should ALLOW it, and we can be clearer in GNAP that that’s 
> one possible model, but not the only one, and not even the general one.
> The AS manages all of the information and interconnections needed to 
> create an access token that the RS will accept, and it is in charge of 
> signaling to the RS what that token’s good for.

I disagree: the AS is NOT in charge of signaling to the RS what that 
token’s good for. It is up to the RS to decide which privileges it will 
accept
among all the privileges included into an access token.

> However, if the AS can learn through some other means that a specific 
> identified user has consented and provided appropriate information in 
> a trusted way,
> then THAT information can be baked into the token by the AS. — 
> importantly,_/in a way that the RS’s the AS protects can understand/_.

I disagree: Trust relationships are not bilateral but only unilateral. 
An AS does not need to have any specific prior relationship with a given 
RS.
It is up to the RS(s) to decide which AS_*(s)*_ it trust(s) *and for 
which privileges*.

> This last bit is where general _/opacity of tokens/_ is important 
> here. There’s a natural security boundary that arises from this model. 
> What I’m proposing here is just that we’re more explicit about what 
> can be put INTO that boundary. That’s where I’m seeing a lot of this 
> innovation in the SSI space fitting. You’re not coming up with some 
> universal access token that the RS will accept, but you’re able to 
> provide universal claims and artifacts that an AS can process and 
> /_translate into a token the RS will accept and do the right thing with_/.

Your argumentation about token opacity is making the assumption that the 
AS and the RS need to have a prior relationship before any access can 
take place.
While this was valid with OAuth, this is no more valid in the context of 
GNAP.  The client should be able to inform the AS about the access token 
format(s) acceptable to the RS.
Then the client may indicate to the AS these acceptable formats. If the 
RS and the AS have an access token format in common, then the process 
may continue.

When only attributes (i.e. not rights) are being requested to an AS by 
the client, the client does not need to disclose the identity of the RS 
to the AS,
which has the major advantage to prevent the AS to act as Big Brother.

_Note_: this does not preclude the use of rights, in particular in the 
context of a single organization or enterprise.

Denis

>
>  — Justin
>
>> On Feb 21, 2021, at 9:40 AM, Adrian Gropper <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hi Torsten,
>>
>> Thank you for raising all of these excellent points. I hope we can 
>> all answer them and maybe even add a section to the wiki. I'll start...
>>
>> You're right that OAuth deployments almost exclusively put the AS and 
>> RS in the same domain. If OAuth were adequate to today's needs we 
>> probably would not be here doing GNAP. Since OAuth, we have 
>> increasing privacy concerns and security disasters. GDPR, for 
>> example, separates the role of a data controller from a data 
>> processor and treats them as separate legal entities. To oversimplify 
>> GDPR, the data processor is spared privacy responsibility and cost.
>>
>> You are also right to mention open banking as a use-case. Open 
>> banking has not adopted UMA 2.0 (on which I have worked for almost a 
>> decade) which is based on OAuth. PSD2 and similar regulations do not 
>> tie the AS and RS to the same security domain but they presume a 
>> narrow federation of licensed (and regulated) ASs as payment 
>> processors for subjects to choose among. This centralization to 
>> regulated fiduciaries is a privacy trade-off that makes sense in 
>> banking. The fiduciary can be bonded so they can refund the money to 
>> the subject in case of a security breach. This privacy-security 
>> tradeoff does not make sense in healthcare and other domains where 
>> the consequences of a breach are not easily reversed.
>>
>> centralization, censorship, or surveillance. If GNAP makes any 
>> assumptions that result in either a tight coupling between AS and RS 
>> (surveillance) or even a federated fiduciary (centralization) we will 
>> lose out on the benefits of progress in digital identity that is now 
>> driving a lot of public-sector initiatives and starting to bleed over 
>> into private sector practices. Zero Trust Architecture is an example 
>> and OAuth is not well suited for ZTA.
>>
>> relationship and agreed on ways to share authorization and user data 
>> in order [to] enable secure API access." This is where GNAP operates 
>> and we need to avoid _any_ restrictions on either the AS or the RS 
>> being self-sovereign. Examples of a self-sovereign RS could be a 
>> personal data store or an encrypted data vault like the ones we work 
>> on in W3C/DIF. Any AS can be self-sovereign if the subject controls 
>> all of the policies and these policies are not shared, in the same 
>> way a private key is never not shared.
>>
>> Continuing your quote:
>>
>>     I read your ideas regarding self-sovereign ASs with great
>>     interest and got some observations/questions:
>>     - A personal AS could certainly control access to a person‘s
>>     resources. I assume the person‘s RSs would only accept access
>>     tokens signed by the RO. Am I right?
>>
>> Encrypted Data Vault should respond to capabilities or tokens. Either 
>> way, the RO is in control of the signature but a personal AS is a 
>> delegate of the RO (either directly or via a mobile user agent). With 
>> capabilities such as ZCAP-LD or biscuits, the token signature allows 
>> for filtered delegation.
>>
>>     - Do you envision this AS to be able to control access to any
>>     kind of RS? How is the AS supposed to know what authorization
>>     data this RS needs in order to perform access control decisions?
>>     What data will be exchanged?
>>
>> Yes. The whole point, as far as I'm concerned, is to design human 
>> centered standards. This is how W3C and IETF are different. Other 
>> SDOs tend to be operated for institutional benefit. A person-centered 
>> AS must work across institutional domains.
>>
>> This, as you point out, brings up the problem of scope. Ontologies 
>> and data models are, justifiably, domain-specific. I, for example, 
>> work around the HL7 data model standards and APIs like FHIR that are 
>> controlled by healthcare business interests. It's unreasonable to 
>> expect a general solution to the data model problem, although folks 
>> of the Linked Data persuasion might disagree.
>>
>> Every RS gets to decide what data models and ontologies it supports. 
>> These decisions are public and sometimes standardized for the benefit 
>> of the clients. A person's AS must read and maybe understand the RS 
>> data model in order to issue tokens just like the client needs to do 
>> in order to make a request to the AS. In our HIE of One Trustee 
>> project, we allow the self-sovereign subject to inherit AS policies 
>> from self-sovereign communities they choose and then modify the 
>> policies if they want. In this way, communities compete for members 
>> on the basis of policy bundles the same way churches compete for 
>> congregants.
>>
>> There are two "persons" to consider. The RO delegates to an RQ. But 
>> the RQ, in real life, is part of a team and often delegates to 
>> associates. With or without capabilities, GNAP needs to deal with 
>> this reality that RO and RQ user agents may be different from the 
>> client that actually presents a token to the RS. Some of this 
>> difference between user agents and clients we may be able to keep out 
>> of band.
>>
>> started HIE of One before SSI in order to drive the transition from 
>> UMA to UMA 2.0 and inform various healthcare regulatory priorities. 
>> We then jumped on SSI immediately and added it to the UMA 2 AS we 
>> call Trustee. Now we are trying to align SSI and GNAP in order to 
>> enable human-centered protocols and zero-trust architecture.
>>
>> Right now, the human-centered user experience assumes a secure 
>> element and web browser as user agents on a mobile device. Neither of 
>> these is readily accessible as a server nor are they designed to 
>> accept code plug-ins that represent the policies of an AS. One major 
>> exception is people adding advertising and surveillance blockers like 
>> EFF Privacy Badger to their browser.
>>
>> The user experience implications of having SSI data model standards 
>> and GNAP protocol standards is that today's password managers (I have 
>> 250 RS relationships in mine) will evolve to also control an AS 
>> agent. Just like I might register a W3C DID with an RS instead of an 
>> email address, my policy manager might display to me the token 
>> policies that will be applied by my AS to the personal data I can 
>> control at that RS.
>>
>> In some cases, my AS will allow me to modify those policies just like 
>> the obnoxious cookie policy settings do today. The BIG difference 
>> with GNAP is that I choose my AS separately from the RS so the dark 
>> patterns associated with today's cookie policies experience are no 
>> longer possible. GNAP means the RS exposes an API rather than a UI.
>>
>> I've gone on far too long to address the issue of the AS as an 
>> identity provider. It's fair to think of it that way. As it turns 
>> out, in the SSI Secure Data Storage WG, we are debating the 
>> difference between an Encrypted Data Vault and an Identity Hub. As 
>> far as I'm concerned, the Identity Hub is mostly a GNAP AS. Join us 
>> on Thursdays at 4 PM ET 
>> <https://lists.identity.foundation/g/sds-wg/wiki/Home>
>>
>> Adrian
>>
>>
>>
>> On Sun, Feb 21, 2021 at 4:34 AM Torsten Lodderstedt 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>
>>
>>>     Am 19.02.2021 um 23:50 schrieb Adrian Gropper
>>>     <[email-masked] <mailto:[email-masked]>>:
>>>
>>>     
>>     the OAuth deployments I‘m aware of typically have much more RSs
>>     than ASs. Why? Because AS and a set of RSs belong to the same
>>     security domain (e.g. a certain business) and it’s the AS’s
>>     responsibility to ensure secure and convenient access to the APIs
>>     provided by this RSs. For example: there is a AS controlling
>>     access to a cloud, streaming, and messaging services of the same
>>     business. In case of open banking, the bank‘s AS is (on behalf of
>>     the user) authorizing access to APIs for account information as
>>     well as payment initiation and potentially other services.
>>
>>     Technically, the respective AS and RSs set up a trust
>>     relationship and agreed on ways to share authorization and user
>>     data in order enable secure API access.
>>
>>     I read your ideas regarding self-sovereign ASs with great
>>     interest and got some observations/questions:
>>     - A personal AS could certainly control access to a person‘s
>>     resources. I assume the person‘s RSs would only accept access
>>     tokens signed by the RO. Am I right?
>>     - Do you envision this AS to be able to control access to any
>>     kind of RS? How is the AS supposed to know what authorization
>>     data this RS needs in order to perform access control decisions?
>>     What data will be exchanged?
>>     In my experience coupling between AS and RS is very tight. I have
>>     a hard time to see how self-sovereign ASs would work. It feels
>>     like such an AS in the end is an identity provider of some sort,
>>     which brings me to what Justin proposed. I would assume using SSI
>>     credentials to authenticate towards ASs is feasible and might
>>     have value but I‘m skeptical about the AS part.
>>
>>     best regards,
>>     Torsten.
>>
>>>     From a human-centered (and hopefully IETF) perspective, each
>>>     person might control or specify a different AS for each of their
>>>     personas or for each child or incompetent delegate of them as
>>>     guardian. We're familiar with separate gmail addresses for each
>>>     persona.
>>>
>>>     ASs will be self-sovereign (as in SSI), fiduciary (as in a
>>>     custodial bitcoin wallet), or brokers (as in data brokers and
>>>     surveillance capitalism). Any RS that is willing to have a
>>>     recurring relationship with a persona could accept a GNAP AS
>>>     endpoint instead of an email address. This is easiest using
>>>     HTTP, but GNAP need not exclude other RS / AS APIs and
>>>     transports. Designing around the uncensored specification of
>>>     one's AS as a human right would greatly simplify many aspects of
>>>     GNAP adoption.
>>>
>>>     jurisdictional reasons to limit the authority of the AS. UMA 2.0
>>>     spent years dancing around this issue with ideas like
>>>     "cascading" AS and various centralized or federated AS concepts.
>>>     My conclusion is that any RS can always do whatever it wants and
>>>     there's not much the authorization protocol can help with other
>>>     than specifying a notification endpoint so that an RS can warn
>>>     (and seek confirmation) or log various exceptions. This turns
>>>     out to be, after a year of testimony, the regulation that
>>>     applies to HIPAA RS APIs in the US. For this reason GNAP might
>>>     include a notification protocol in the AS specification, or not.
>>>
>>>>         On Feb 18, 2021, at 7:59 PM, Tobias Looker
>>>>         <[email-masked]
>>>>         <mailto:[email-masked]>> wrote:
>>>>
>>>>         Justin,
>>>>
>>>>         I think this is a great and timely conversation to be
>>>>         having given the current interest around SSI and efforts
>>>>         like SIOP, I have been doing quite a bit of work in this
>>>>         space as of recent, so thought I'd add a few of the
>>>>         In my opinion SIOP was really a bucket for solving quite a
>>>>         few different problems, not just one. In particular I think
>>>>         its intent was to solve 3 major ones:
>>>>
>>>>         *Enabling portable identities *- In general today in the
>>>>         case of OpenID, the end-users identity as understood by a
>>>>         relying party is scoped within the domain of the provider.
>>>>         Which means if that provider goes out of business or for
>>>>         whatever reason decides to no longer offer the same
>>>>         identity services to the End-User, their identity is
>>>>         essentially gone. Whilst there has been some interesting
>>>>         related work from groups like MODRNA on solutions to combat
>>>>         this like 'Account Porting', they often assume the old
>>>>         provider remains online and willing to facilitate in the
>>>>         account porting process so that the End-User can migrate to
>>>>         a new provider. SIOP actually elected to do something
>>>>         different here by using cryptography, instead of the
>>>>         End-User identifier being something like a GUID asserted
>>>>         within the domain of the provider, SIOP defined this
>>>>         instead as a public key fingerprint associated to a private
>>>>         key that's assumed to be under the control of the user. In
>>>>         doing so the identity itself becomes portable between
>>>>         providers by transferring the associated private key. Now
>>>>         this approach does have drawbacks and arguably encourages
>>>>         what many would refer to as bad cryptographic practise by
>>>>         not allowing any way to do key rotation, however the idea
>>>>         was there.
>>>>
>>>>         *How GNAP can solve for this?* By having flexibility around
>>>>         how the resource owner / End-User is referred to by the
>>>>         Authorization server (e.g allow the identifier to be
>>>>         something like a public key or a resolvable identifier to
>>>>         public keys such as a DID)
>>>
>>>         I personally think that GNAP should be a flexible :carrier:
>>>         of identifiers and other bits of identity information. This
>>>         is the main reason we went with the Subject Identifiers
>>>         draft from SECEVENT: it’s set up to talk about a variety of
>>>         different kinds of identifiers, all of them asserted in the
>>>         context of the AS. If there’s a definition for a DID URL or
>>>         a JWK in the sub_ids object structure, GNAP would be able to
>>>         just use it directly alongside every other format. I haven’t
>>>         seen those proposed yet, but it would be easy to do and, in
>>>         my mind, would be a better solution than the portable
>>>         identifiers proposal that was recently brought up in the
>>>         FAPI working group in OIDF. (A side note, but the main
>>>         problem I have here is that it’s pasting semantics and
>>>         formats onto a field where none existed before, and that’s
>>>         rife for problems. Better to have a structure that takes
>>>>         *Solving the NASCAR problem *- One of those enduring
>>>>         problems in identity systems, which I think is really about
>>>>         the three way negotiation going on between the RP, the
>>>>         End-User and the Provider. SIOP's solution pushed for most
>>>>         of the power in this decision making process to lie with
>>>>         the End-User, letting them decide who they want as their
>>>>         provider rather than RP's providing an enumeration of who
>>>>         they support via provider icons on their login page and
>>>>         End-Users having to select from those options. It
>>>>         accomplished this via using a custom URL scheme of
>>>>         `openid://` where the End-User would register their chosen
>>>>         provider as a protocol handler for the `openid://` scheme.
>>>>         However, again as a solution it's not without it's
>>>>         challenges, notably; only a single registration at a time
>>>>         can be supported, the actual identity of the provider
>>>>         remains blind to the RP until after the request is sent and
>>>>         it requires registration or some form of default handling
>>>>         (e.g when there is no provider registered).
>>>>
>>>>         *How GNAP can solve for this?* I actually don't think this
>>>>         is core to GNAP, there may be some considerations around
>>>>         discovery that are worth paying attention to but not much
>>>>         in the core protocol design.
>>>>
>>>
>>>         SIOP doesn’t really solve the NASCAR issue since SIOP, by
>>>         design, becomes yet one more login option among many. I
>>>         think GNAP can help this by enabling user-directed provider
>>>         discovery to kick off the process, but I agree that the core
>>>         protocol doesn’t really have much to say here, and shouldn’t.
>>>
>>>>         *Exploring different deployment models for the provider* -
>>>>         This is the most frequently talked about aspect of SIOP and
>>>>         perhaps the most interesting to GNAP. I like to think about
>>>>         the scope of this issue as designing to allow for either a
>>>>         partially or fully distributed/decentralized provider,
>>>>         rather than a centralized one (e.g an HTTP based AuthZ
>>>>         server). As you noted this does come with its challenges
>>>>         many of which are technical in nature, i.e how to
>>>>         appropriately address a decentralized provider and what
>>>>         protocols are used to communicate with the provider.
>>>>
>>>>         *How GNAP can solve for this?* I think that's what much of
>>>>         the discussion on this thread will be about and whether
>>>>         there is a hybrid model where some responsibility is still
>>>>         centrally administered like token issuance, while allowing
>>>>         other aspects to occur in a more distributed manner.
>>>>         Ideally though I'd like to see consideration for a
>>>>         completely distributed model too.
>>>
>>>         I agree that this seems to be the most interesting place for
>>>         overlap. I don’t actually think the “hybrid” approach
>>>         centralizes things. Instead, you can think of the RS as
>>>         having an associated AS, and that AS accepting user consent
>>>         and claims at runtime from a variety of sources (wallets,
>>>         VCs, etc.). In this way, we aren’t talking about a single AS
>>>         in the world handling all of these requests, we’re talking
>>>         about a distributed network of AS’s associated with an even
>>>         more widely distributed set of RS’s. SSI and its associated
>>>         technologies would help these “local” AS’s issue access
>>>         tokens without the RO needing to have an account, or even
>>>         necessarily directly interacting with the AS. There’s
>>>         currently a technology gap there, but my thoughts are that
>>>         this is where the changes to the interaction modes section
>>>         can really come to play.
>>>
>>>         I think the notion of a non-HTTP AS is interesting, but I’m
>>>         not sure if that’s something GNAP ought to be solving for. I
>>>         think that there’s a deep value in building on top of HTTP
>>>         for the core protocol, and not abstracting away concepts
>>>         from it. Otherwise, you end up re-inventing layers, and you
>>>>         Mattr website
>>>>         Mattr website
>>>>         	Mattr on LinkedIn
>>>>         <https://www.google.com/url?q=https://www.linkedin.com/company/mattrglobal&source=gmail-imap&ust=1614379828000000&usg=AOvVaw3lMMq8NBc2SQydPN2L456A>
>>>>         	Mattr on Twitter
>>>>         <https://www.google.com/url?q=https://twitter.com/mattrglobal&source=gmail-imap&ust=1614379828000000&usg=AOvVaw0zeSL9sn_ak-UOBMq0yPqv>
>>>>         	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, Feb 18, 2021 at 9:19 PM Fabien Imbault
>>>>         <[email-masked]
>>>>         <mailto:[email-masked]>> wrote:
>>>>
>>>>             Hi Justin,
>>>>
>>>>             I agree that defining AS role primarily as a token
>>>>             issuer is a fruitful idea. Solving this problem well
>>>>             would also respond to the challenges discussed
>>>>             previously on the list.
>>>>
>>>>             Cheers
>>>>             Fabien
>>>>
>>>>
>>>>             Le mer. 17 févr. 2021 à 23:27, Justin Richer
>>>>             <[email-masked] <mailto:[email-masked]>> a écrit :
>>>>
>>>>                 The last interim call had a lot of discussion on
>>>>                 SSI technologies such as digital wallets, and how
>>>>                 those fit with GNAP. I think it’s worth continuing
>>>>                 that conversation here on the list. There are a few
>>>>                 issues in the tracker that give some background, too:
>>>>
>>>>                 There’s been a lot of interesting work recently in
>>>>                 the OpenID Foundation around using the Self-issued
>>>>                 OP (SIOP) functionality to bootstrap an SSI style
>>>>                 login. This makes extensive use of the implicit
>>>>                 flow and front channel messaging, but minimization
>>>>                 of the front channel for message passing is a key
>>>>                 design tenet of GNAP (so much so that it’s included
>>>>                 in our charter). Instead, GNAP has been built
>>>>                 around an idea that everything starts the same way:
>>>>                 with an HTTP request to the AS.
>>>>
>>>>                 The idea of an on-device AS has been brought up a
>>>>                 lot, and we need to consider if and how we want to
>>>>                 deal with these kinds of use cases. The most
>>>>                 obvious way to address these would be to do some
>>>>                 kind of clever off-HTTP hack like SIOP, but keep in
>>>>                 mind that even SIOP generally starts off with an
>>>>                 HTTP-based discovery call by the RP to make things
>>>>                 work.
>>>>
>>>>                 My personal stance is that to do this, we need to
>>>>                 re-evaluate our assumptions about exactly what an
>>>>                 AS does and what it needs to do those things. In
>>>>                 OAuth 2, it’s assumed that the AS is the device
>>>>                 that’s authenticating the user, collecting consent,
>>>>                 managing the client’s registration, and creating an
>>>>                 access token based on whatever set of rights that
>>>>                 are associated with all of those things. In UMA,
>>>>                 this is turned around a bit by letting the RO
>>>>                 present a bunch of nebulous “claims” interactively,
>>>>                 but still at the AS.
>>>>
>>>>                 With both of these, a key aspect remains: the AS
>>>>                 needs to gather necessary information, and issue
>>>>                 the access token (or identifiers/assertions).
>>>>                 Because of how the protocol works, the client
>>>>                 software now has a better opportunity to present
>>>>                 information to the AS, either directly in the
>>>>                 request or by introducing the AS to another
>>>>                 software component during the “interaction” phase.
>>>>                 So, what if we think of the AS primarily as a
>>>>                 “token issuer”?
>>>>
>>>>                 For example, if the client can present a verifiable
>>>>                 credential (VC) that represents the end user, the
>>>>                 AS can validate that VC and make an access token on
>>>>                 behalf of that user, without having the user log in
>>>>                 or interact with the AS at all. This VC can contain
>>>>                 whatever access rights the token needs to
>>>>                 represent, and the AS can translate that into an
>>>>                 artifact that the downstream RS’s can interpret,
>>>>                 without having to see the original VC or the user
>>>>                 at all. The AS is still HTTP based, but all the
>>>>                 essential security and rights elements are provided
>>>>                 by the wallet. In this way, we can expand on the
>>>>                 privacy-preserving aspects of OAuth and bridge the
>>>>                 worlds of SSI and web APIs without violating the
>>>>                 basic nature of either.
>>>>
>>>>                 Coming from the OAuth world, it feels weird to
>>>>                 issue tokens like this, but there’s precedent for
>>>>                 this kind of thing. Today, a there are a number of
>>>>                 service-based OAuth AS's that are told what claims
>>>>                 need to get put into the access token by some
>>>>                 trusted component. All of this happens outside the
>>>>                 OAuth protocol. In GNAP, I think it makes sense to
>>>>                 account for this kind of thing in how we define the
>>>>                 protocol. That isn’t to say all of these pieces
>>>>                 need to be defined in the core, but the base
>>>>                 protocol ought to be able to handle being extended
>>>>                 in this direction as needed.
>>>>
>>>>                 I’m really interested to hear other people’s
>>>>                 thoughts on how this could come together.
>>>>
>>>>                  — Justin
>>>>                 -- 
>>>>                 TXAuth mailing list

---

From: Francis Pouatcha <[email-masked]>
Date: Wed, 24 Feb 2021 17:08:49 +0000

Integrating GNAP and SSI requires a lot of fundamentals:

  *   AS had their essence in the fact that human held devices were not able to produce authorization sharable to client and RS
  *   If the human held device can do the work, it is natural the momentum will shift in that direction. This is what is happening with SSI.
  *   Sharing all views of Adrian mention in this thread(no need to repeat).
  *   But repeating the keyword: ZTA. Keeping custodian, server centered architectures under control is getting tougher as time goes by.

In GNAP initial discussion, we walked through a lot of abstract diagram, that could have allowed production of authorization and authentication material (token) by human held devices. The intention was inspired from SSI discussions.

IF
  Justin is asking to reconsider an integration of SSI,

THEN
we need to review the abstract protocol flows:

  *   roles
  *   entities
  *   relationships

We will have to start by taking the http protocol constraint out of the charter.

BTW

  *   I agree with Justin: "The RS decides on how to consume a presented token."
  *   I agree with Denis: "AS plays no role and shall have no influence on the RS decision on how to consume a token."

THEN
We must start by sharping the meaning of an AS (in the context of GNAP). Discussion might lead to a retirement of this term. As mortals might have a hard time considering a user held device a server.

END IF

Nevertheless, the transition from (http)-AS based token production to user device-based token production will need some 10+ years to complete. Still a lot of challenges around how to protect keys held on user devices against damage, loss of device, malware, ransomware, social engineered attack.

Can GNAP be the main vehicle for this transition? Maybe. Despite the (too) strong reliance on the OAuth legacy (even if GNAP does not promise backward compatibility to OAuth), an embedded interaction that allows the client to carry the user device produced token to the resource server might pave way for this transition. I campaigned for consideration of an embedded interaction in the initial conversation. I am not sure this was taken into account. Still must find time to review the current draft.

/Francis

________________________________
From: TXAuth <[email-masked]> on behalf of Denis <[email-masked]>
Sent: Tuesday, February 23, 2021 12:51 PM
To: Justin Richer <[email-masked]>; txauth gnap <[email-masked]>
Subject: Re: [GNAP] Integrating a GNAP AS with wallets and SSI

Hi  Justin,

See my comments between the lines.
An important aspect in the discussion here, that I agree with, is that the RS needs to be able to decide which AS it talks to.

 While I would agree with such a sentence in the OAuth WG, I don't believe that this sentence is applicable in general in the context of GNAP.
A RS does not need to "talk to" any AS. A RS decides which AS(s) it trusts to issue access tokens that contains some set of privileges.

But inherent in that is that it’s not the user’s decision, or the AS’s decision, it’s the RS’s decision who it will trust to get tokens from.

A RS does not necessarily need to trust all the access tokens issued by a given AS, but only access tokens from a given AS that contain
a given set of privileges.

And no matter what our philosophy, at the end of the day the RS will always have the choice of whether to trust an inbound request.

Which is why, to me, this really brings us to the question of what an AS provides. The AS gives the RS a token that the RS decides to trust,
and that the RS can understand (either directly with something like JWT or indirectly with something like introspection).
But the AS also needs to decide what to put INTO that token. As a consequence, the AS can get that information from any number of places.
The information could be provided in a trusted way by the end user to the AS — but this does NOT necessarily mean that the AS belongs
to the user or is under their control.

Basically, I think we’re trying to hard to map the OAuth general-concept of the RO having an account at the AS and logging in to it before authorizing the request.
I think that the call for “every user to have their own AS” is such a huge non-starter in so many domains that it hampers the solution space if that’s what we presume.
It’s up to the RS to decide who it trusts, not the end user and not the RO.

I think we should ALLOW it, and we can be clearer in GNAP that that’s one possible model, but not the only one, and not even the general one.
The AS manages all of the information and interconnections needed to create an access token that the RS will accept, and it is in charge of signaling to the RS what that token’s good for.

I disagree: the AS is NOT in charge of signaling to the RS what that token’s good for. It is up to the RS to decide which privileges it will accept
among all the privileges included into an access token.

However, if the AS can learn through some other means that a specific identified user has consented and provided appropriate information in a trusted way,
then THAT information can be baked into the token by the AS. — importantly, in a way that the RS’s the AS protects can understand.

I disagree: Trust relationships are not bilateral but only unilateral. An AS does not need to have any specific prior relationship with a given RS.
It is up to the RS(s) to decide which AS(s) it trust(s) and for which privileges.

Your argumentation about token opacity is making the assumption that the AS and the RS need to have a prior relationship before any access can take place.
While this was valid with OAuth, this is no more valid in the context of GNAP.  The client should be able to inform the AS about the access token format(s) acceptable to the RS.
Then the client may indicate to the AS these acceptable formats. If the RS and the AS have an access token format in common, then the process may continue.

When only attributes (i.e. not rights) are being requested to an AS by the client, the client does not need to disclose the identity of the RS to the AS,
which has the major advantage to prevent the AS to act as Big Brother.

    Note: this does not preclude the use of rights, in particular in the context of a single organization or enterprise.

Denis

 — Justin

On Feb 21, 2021, at 9:40 AM, Adrian Gropper <[email-masked]<mailto:[email-masked]>> wrote:

Hi Torsten,

Continuing your quote:

I've gone on far too long to address the issue of the AS as an identity provider. It's fair to think of it that way. As it turns out, in the SSI Secure Data Storage WG, we are debating the difference between an Encrypted Data Vault and an Identity Hub. As far as I'm concerned, the Identity Hub is mostly a GNAP AS. Join us on Thursdays at 4 PM ET https://lists.identity.foundation/g/sds-wg/wiki/Home

Adrian

On Sun, Feb 21, 2021 at 4:34 AM Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>> wrote:

Am 19.02.2021 um 23:50 schrieb Adrian Gropper <[email-masked]<mailto:[email-masked]>>:

best regards,
Torsten.

Adrian

On Fri, Feb 19, 2021 at 2:30 PM Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:
Tobias, thanks for the great observations. Some reactions inline below.

On Feb 18, 2021, at 7:59 PM, Tobias Looker <[email-masked]<mailto:[email-masked]>> wrote:

Justin,

 — Justin

Thanks,
[Mattr                                                           website]<https://www.google.com/url?q=https://mattr.global/&source=gmail-imap&ust=1614379828000000&usg=AOvVaw2w9AL-TL2QlHO6RwxqWQyZ>
Tobias Looker
Mattr
+64 (0) 27 378 0461
[email-masked]<mailto:[email-masked]>
[Mattr website]<https://www.google.com/url?q=https://mattr.global/&source=gmail-imap&ust=1614379828000000&usg=AOvVaw2w9AL-TL2QlHO6RwxqWQyZ>     [Mattr on                                                           LinkedIn] <https://www.google.com/url?q=https://www.linkedin.com/company/mattrglobal&source=gmail-imap&ust=1614379828000000&usg=AOvVaw3lMMq8NBc2SQydPN2L456A>       [Mattr on                                                           Twitter] <https://www.google.com/url?q=https://twitter.com/mattrglobal&source=gmail-imap&ust=1614379828000000&usg=AOvVaw0zeSL9sn_ak-UOBMq0yPqv>     [Mattr on                                                           Github] <https://www.google.com/url?q=https://github.com/mattrglobal&source=gmail-imap&ust=1614379828000000&usg=AOvVaw2D-EXKiFVwiOXynoCnYOVQ>

On Thu, Feb 18, 2021 at 9:19 PM Fabien Imbault <[email-masked]<mailto:[email-masked]>> wrote:
Hi Justin,

Cheers
Fabien

Le mer. 17 févr. 2021 à 23:27, Justin Richer <[email-masked]<mailto:[email-masked]>> a écrit :
The last interim call had a lot of discussion on SSI technologies such as digital wallets, and how those fit with GNAP. I think it’s worth continuing that conversation here on the list. There are a few issues in the tracker that give some background, too:

https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/175<https://www.google.com/url?q=https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/175&source=gmail-imap&ust=1614379828000000&usg=AOvVaw1qnd2F79zmQk_LGtaysKeP>

 — Justin
--
TXAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/txauth<https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/txauth&source=gmail-imap&ust=1614379828000000&usg=AOvVaw3avsUGQ48fo1OUQV0vyyKd>
--
TXAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/txauth<https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/txauth&source=gmail-imap&ust=1614379828000000&usg=AOvVaw3avsUGQ48fo1OUQV0vyyKd>

--
TXAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/txauth<https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/txauth&source=gmail-imap&ust=1614379828000000&usg=AOvVaw3avsUGQ48fo1OUQV0vyyKd>
--
TXAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/txauth&source=gmail-imap&ust=1614379828000000&usg=AOvVaw3avsUGQ48fo1OUQV0vyyKd

---

From: Adrian Gropper <[email-masked]>
Date: Wed, 24 Feb 2021 12:47:17 -0500

It might help the GNAP scoping discussion relative to SSI if we consider
two separate domains:
- *Registration:* The relationship between the RO and the RS prior to any
GNAP Client entering the picture, and
- *Authorization:* The interaction protocols between the user agents of end
users and servers

Fact: Only two SSI standards (VC and DID) are established enough for us to
reference in GNAP and they are both merely data models, not protocols.
Neither of these data models is particularly concerned with delegation
protocols although there is going to be some impact from things like
multi-signature schemes and filtering of capabilities.

IMHO, GNAP as a delegation protocol standard cannot presume the success or
applicability of any SSI inspired protocols, including DIDcomm or
Confidential Storage, that are still trying to figure out their
relationship to HTTP.

Also, IMHO, SSI is not synonymous with protocols that presume a Holder as a
mandated intermediary store for any attribute that moves between an issuer
and a verifier. There are many, maybe most, use cases where SSI would be
better served by control of the attribute over actual possession of the
attribute.

Adrian

On Wed, Feb 24, 2021 at 12:09 PM Francis Pouatcha <fpo=
[email-masked]> wrote:

>    - AS had their essence in the fact that human held devices were not
>    able to produce authorization sharable to client and RS
>    - If the human held device can do the work, it is natural the momentum
>    will shift in that direction. This is what is happening with SSI.
>    - Sharing all views of Adrian mention in this thread(no need to
>    repeat).
>    - But repeating the keyword: ZTA. Keeping custodian, server centered
>    architectures under control is getting tougher as time goes by.
>
> In GNAP initial discussion, we walked through a lot of abstract diagram,
> that could have allowed production of authorization and authentication
> material (token) by human held devices. The intention was inspired from SSI
> discussions.
>
> IF
>    - roles
>    - entities
>    - relationships
>    - I agree with Justin: "The RS decides on how to consume a presented
>    token."
>    - I agree with Denis: "AS plays no role and shall have no influence on
>    the RS decision on how to consume a token."
>
>
> THEN
> We must start by sharping the meaning of an AS (in the context of GNAP).
> Discussion might lead to a retirement of this term. As mortals might have a
> hard time considering a user held device a server.
>
> END IF
>
>
> Nevertheless, the transition from (http)-AS based token production to user
> device-based token production will need some 10+ years to complete. Still a
> lot of challenges around how to protect keys held on user devices against
> damage, loss of device, malware, ransomware, social engineered attack.
>
> Can GNAP be the main vehicle for this transition? Maybe. Despite the (too)
> strong reliance on the OAuth legacy (even if GNAP does not promise backward
> compatibility to OAuth), an *embedded* interaction that allows the client
> to carry the user device produced token to the resource server might pave
> way for this transition. I campaigned for consideration of an *embedded
> interaction* in the initial conversation. I am not sure this was taken
> into account. Still must find time to review the current draft.
>
>
> /Francis
>
>
> ------------------------------
> *From:* TXAuth <[email-masked]> on behalf of Denis <
> [email-masked]>
> *Sent:* Tuesday, February 23, 2021 12:51 PM
> *To:* Justin Richer <[email-masked]>; txauth gnap <[email-masked]>
> *Subject:* Re: [GNAP] Integrating a GNAP AS with wallets and SSI
>
> Hi  Justin,
>
> An important aspect in the discussion here, that I agree with, is that the
> RS needs to be able to decide *which AS it talks to*.
>
>  While I would agree with such a sentence in the OAuth WG, I don't believe
> that this sentence is applicable in general in the context of GNAP.
> A RS does not need to "talk to" any AS. A RS decides which AS(s) it trusts
> to issue access tokens *that contains some set of privileges*.
>
> A RS does not necessarily need to trust all the access tokens issued by a
> given AS, but only access tokens from a given AS that contain
> Which is why, to me, this really brings us to the question of what an AS
> provides. The AS gives the RS a token that the RS decides to trust,
> and that the RS can understand (either directly with something like JWT or
> indirectly with something like introspection).
> The information could be provided in a trusted way by the end user to the
> AS — but this does NOT necessarily mean that the AS belongs
> Basically, I think we’re trying to hard to map the OAuth general-concept
> of the RO having an account at the AS and logging in to it before
> authorizing the request.
> I think that the call for “every user to have their own AS” is such a huge
> non-starter in so many domains that it hampers the solution space if that’s
> what we presume.
> I think we should ALLOW it, and we can be clearer in GNAP that that’s one
> possible model, but not the only one, and not even the general one.
> identified user has consented and provided appropriate information in a
> trusted way,
> then THAT information can be baked into the token by the AS. — importantly,*
> in a way that the RS’s the AS protects can understand*.
>
> I disagree: Trust relationships are not bilateral but only unilateral. An
> AS does not need to have any specific prior relationship with a given RS.
> It is up to the RS(s) to decide which AS*(s)* it trust(s) *and for which
> privileges*.
>
> This last bit is where general *opacity of tokens* is important here.
> There’s a natural security boundary that arises from this model. What I’m
> proposing here is just that we’re more explicit about what can be put INTO
> that boundary. That’s where I’m seeing a lot of this innovation in the SSI
> space fitting. You’re not coming up with some universal access token that
> the RS will accept, but you’re able to provide universal claims and
> artifacts that an AS can process and *translate into a token the RS will
> accept and do the right thing with*.
>
> AS and the RS need to have a prior relationship before any access can take
> place.
> Then the client may indicate to the AS these acceptable formats. If the RS
> and the AS have an access token format in common, then the process may
> continue.
>
> When only attributes (i.e. not rights) are being requested to an AS by the
> client, the client does not need to disclose the identity of the RS to the
> AS,
>     *Note*: this does not preclude the use of rights, in particular in
> the context of a single organization or enterprise.
>
> Denis
>
>
>  — Justin
>
> You're right that OAuth deployments almost exclusively put the AS and RS
> in the same domain. If OAuth were adequate to today's needs we probably
> would not be here doing GNAP. Since OAuth, we have increasing privacy
> concerns and security disasters. GDPR, for example, separates the role of a
> data controller from a data processor and treats them as separate legal
> This, as you point out, brings up the problem of scope. Ontologies and
> data models are, justifiably, domain-specific. I, for example, work around
> the HL7 data model standards and APIs like FHIR that are controlled by
> There are two "persons" to consider. The RO delegates to an RQ. But the
> RQ, in real life, is part of a team and often delegates to associates. With
> or without capabilities, GNAP needs to deal with this reality that RO and
> RQ user agents may be different from the client that actually presents a
> token to the RS. Some of this difference between user agents and clients we
> may be able to keep out of band.
>
> On Sun, Feb 21, 2021 at 4:34 AM Torsten Lodderstedt <
> [email-masked]> wrote:
>
>
>

---

From: Justin Richer <[email-masked]>
Date: Wed, 24 Feb 2021 13:58:01 -0500

+1 to this. In my opinion, building on anything other than HTTP right now is speculation, at best. And building an abstraction from zero-to-one concrete manifestations is a recipe for disaster. Once a second thing comes along, you inevitably realize that you put the abstraction points in the wrong place and have in fact baked in a lot of assumptions about your base case into what was supposed to be an abstraction layer. 

Instead, if there’s a desire to build out GNAP on top of other protocols, then it should be :translated: to those protocols. This happened with OAuth being built on top of COAP in ACE, without OAuth defining an abstraction layer ahead of time. And I’ll wager that if we had defined such a layer, it would not have considered things like the multi-tiered client structures that are in ACE, or the key distribution challenges in the IoT environment. Abstractions can come after the fact to aid future translations, but translation is nearly always more practical. 

But my point in starting this thread is that I think we can set up appropriate extension points for novel elements without throwing out the entire base protocol, or creating something overly abstract. So I think we can keep the “AS” component and the central HTTP-based protocol but have places where these other elements, like SSI wallets, can come in. I think we need to get away from the false conclusion that the SSI wallet has to :be: the AS. Instead, I think the SSI wallet can feed information into an AS in order for the AS to do its job.

 — Justin

> On Feb 24, 2021, at 12:47 PM, Adrian Gropper <[email-masked]> wrote:
> 
> It might help the GNAP scoping discussion relative to SSI if we consider two separate domains: 
> - Registration: The relationship between the RO and the RS prior to any GNAP Client entering the picture, and
> - Authorization: The interaction protocols between the user agents of end users and servers
> 
> Fact: Only two SSI standards (VC and DID) are established enough for us to reference in GNAP and they are both merely data models, not protocols. Neither of these data models is particularly concerned with delegation protocols although there is going to be some impact from things like multi-signature schemes and filtering of capabilities.
> 
> IMHO, GNAP as a delegation protocol standard cannot presume the success or applicability of any SSI inspired protocols, including DIDcomm or Confidential Storage, that are still trying to figure out their relationship to HTTP. 
> 
> Also, IMHO, SSI is not synonymous with protocols that presume a Holder as a mandated intermediary store for any attribute that moves between an issuer and a verifier. There are many, maybe most, use cases where SSI would be better served by control of the attribute over actual possession of the attribute.
> 
> Adrian
> 
> 
> 
> On Wed, Feb 24, 2021 at 12:09 PM Francis Pouatcha <fpo=[email-masked] <mailto:[email-masked]>> wrote:
> AS had their essence in the fact that human held devices were not able to produce authorization sharable to client and RS
> If the human held device can do the work, it is natural the momentum will shift in that direction. This is what is happening with SSI.
> Sharing all views of Adrian mention in this thread(no need to repeat). 
> But repeating the keyword: ZTA. Keeping custodian, server centered architectures under control is getting tougher as time goes by.
> roles
> entities
> relationships
> I agree with Justin: "The RS decides on how to consume a presented token."
> I agree with Denis: "AS plays no role and shall have no influence on the RS decision on how to consume a token."
> 
> THEN
> From: TXAuth <[email-masked] <mailto:[email-masked]>> on behalf of Denis <[email-masked] <mailto:[email-masked]>>
> To: Justin Richer <[email-masked] <mailto:[email-masked]>>; txauth gnap <[email-masked] <mailto:[email-masked]>>
>>> On Feb 21, 2021, at 9:40 AM, Adrian Gropper <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hi Torsten,
>>>

---

From: Francis Pouatcha <[email-masked]>
Date: Thu, 25 Feb 2021 01:14:57 +0000

Justin, Adrian,

in my initial contributions, I did refer to SSI just as a sample use case user device generated token. We have a lot of example out there running with Fido, EMV, electronic id cards, passports.

Focus on the SSI philosophy might distract from the main issue: having user device generated cryptograms.

Nevertheless, SSI is a good framework to present the use case.

Let distinguish between:
- a verifiable credential (VC) and
- a verifiable presentation (VP).

A VC might be produced by an authority (let assume an AS) in a direct negotiation between RO and AS. No involvement of the Client.  I will call this a direct interaction.

The VP is produced by the RO and presented to the Client. No involvement of the AS. This is also a direct interaction.

The presentation of this original RO produced VP by a Client to an RS might require a new presentation produced by the Client and warping the  original VP. I call this an embedded interaction. I am missing this one in GNAP.

The ‘Embedded’ suggestion did not make it pass the initial discussion, because we were unable to justify it legitime use to the OAuth legacy folks. We have been using this interaction mode in the banking world for the last 20 years through diverse protocols.

By adopting the embedded interaction, GNAP bridges the way to SSI.

Please to not talk about “embedding user password” a la “password grant”. I am referring to allowing a client carry a cryptogram produced by the RO to the RS.

If we define the producer of the Token to be an AS, the we will have to show a mortal how to run the http based A-(Server) on the user device.

Even if we narrow the definition of the AS to producing the VC and not the VP, we still have a problem, as some VC might be produced by the user.

In the EU we will be witnessing eIDAS certificates issued to user, allowing them to produce their own VC, without the help of server based AS? Shall this make those VC producing applications running on the user device AS? Then we will have to redefine AS.

/Francis

________________________________
From: Francis Pouatcha <[email-masked]>
Sent: Thursday, February 25, 2021 1:13 AM
To: Justin Richer <[email-masked]>; Adrian Gropper <[email-masked]>
Cc: Francis Pouatcha <[email-masked]>; Denis <[email-masked]>; txauth gnap <[email-masked]>
Subject: Re: [GNAP] Integrating a GNAP AS with wallets and SSI

Justin, Adrian,

in my initial contributions, I did refer to SSI just as a sample use case user device generated token. We have a lot of example out there running with Fido, EMV, electronic id cards, passports.

Focus on the SSI philosophy might distract from the main issue: having user device generated cryptograms.

Nevertheless, SSI is a good framework to present the use case.

Let distinguish between:

- a verifiable credential (VC) and

- a verifiable presentation (VP).

A VC might be produced by an authority (let assume an AS) in a direct negotiation between RO and AS. No involvement of the Client.  I will call this a direct interaction.

The VP is produced by the RO and presented to the Client. No involvement of the AS. This is also a direct interaction.

The presentation of this original RO produced VP by a Client to an RS might require a new presentation produced by the Client and warping the  original VP. I call this an embedded interaction. I am missing this one in GNAP.

The ‘Embedded’ suggestion did not make it pass the initial discussion, because we were unable to justify it legitime use to the OAuth legacy folks. We have been using this interaction mode in the banking world for the last 20 years through diverse protocols.

By adopting the embedded interaction, GNAP bridges the way to SSI.

Please to not talk about “embedding user password” a la “password grant”. I am referring to allowing a client carry a cryptogram produced by the RO to the RS.

If we define the producer of the Token to be an AS, the we will have to show a mortal how to run the http based A-(Server) on the user device.

Even if we narrow the definition of the AS to producing the VC and not the VP, we still have a problem, as some VC might be produced by the user.

In the EU we will be witnessing eIDAS certificates issued to user, allowing them to produce their own VC, without the help of server based AS? Shall this make those VC producing applications running on the user device AS? Then we will have to redefine AS.

/Francis

From: Justin Richer <[email-masked]>
Date: Wednesday, February 24, 2021 at 1:58 PM
To: Adrian Gropper <[email-masked]>
Cc: Francis Pouatcha <[email-masked]>, Denis <[email-masked]>, txauth gnap <[email-masked]>
Subject: Re: [GNAP] Integrating a GNAP AS with wallets and SSI

 — Justin

On Feb 24, 2021, at 12:47 PM, Adrian Gropper <[email-masked]<mailto:[email-masked]>> wrote:

Adrian

On Wed, Feb 24, 2021 at 12:09 PM Francis Pouatcha <fpo=[email-masked]<mailto:[email-masked]>> wrote:

IF

THEN

  *   roles
  *   entities
  *   relationships

BTW

THEN

END IF

/Francis

From: TXAuth <[email-masked]<mailto:[email-masked]>> on behalf of Denis <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, February 23, 2021 12:51 PM
To: Justin Richer <[email-masked]<mailto:[email-masked]>>; txauth gnap <[email-masked]<mailto:[email-masked]>>
Subject: Re: [GNAP] Integrating a GNAP AS with wallets and SSI

Hi  Justin,

Denis

 — Justin

Hi Torsten,

Continuing your quote:

Adrian

?

best regards,

Torsten.

Adrian

Justin,

 — Justin

Thanks,

Tobias Looker

Mattr

+64 (0) 27 378 0461

[Mattr on                                                           LinkedIn]<https://www.google.com/url?q=https://www.linkedin.com/company/mattrglobal&source=gmail-imap&ust=1614379828000000&usg=AOvVaw3lMMq8NBc2SQydPN2L456A>

[Mattr on                                                           Twitter]<https://www.google.com/url?q=https://twitter.com/mattrglobal&source=gmail-imap&ust=1614379828000000&usg=AOvVaw0zeSL9sn_ak-UOBMq0yPqv>

[Mattr on                                                           Github]<https://www.google.com/url?q=https://github.com/mattrglobal&source=gmail-imap&ust=1614379828000000&usg=AOvVaw2D-EXKiFVwiOXynoCnYOVQ>

Hi Justin,

Cheers

Fabien

 — Justin

---

From: Adrian Gropper <[email-masked]>
Date: Wed, 24 Feb 2021 21:09:47 -0500

Hi Francis,

I deeply want to understand what use-cases GNAP may be missing but I'm
having trouble understanding your requirement and don't have the benefit of
banking world experience. It doesn't matter to me whether GNAP is missing a
use-case related to SSI or not. I just want to understand any
limitations we might be building into GNAP 1.0

I hope some of this helps us come to a common vocabulary...

1. I think in terms of delegation. The GNAP AS is a delegate of the RO. The
RO (or RQ) uses a user agent to interact with the AS. This user-agent could
be a web browser or a mobile app. I assume that users can choose user
agents that include a HSM such as a FIDO2 or SIM card and I hope that's
encouraged but if an AS wants to deal with username / password, I would not
prohibit that.

2. The RS is another kind of delegation. As with the AS, the RO can
approach the RS directly with a user agent and exercise their privilege of
specifying an AS as their delegate if the RS offers that feature. If the RS
does not offer that feature to the RO, then I don't think GNAP is very
relevant. If the RS restricts the RO's choice of ASs to a list or
federation then GNAP still applies but in this case SSI principles are
likely being trampled.

3. The RQ relationship with the RS is _not_ delegation. It is
authorization. This is true whether the RQ happens to be the RO or a
separate party. I consider the RQ - RS relationship to be mediated by
a Client, not a user agent. In some cases, the RQ user agent is also their
client but I hope that GNAP never makes this assumption. In other words,
the party that interacts with the AS may not be the same as the party that
interacts with the RS because we want to encourage the ability for the RQ
to delegate to another end user and the client of that end user. This is
critical to effective workflows in the real world.

4. This raises issues around the responsibility of the RS to honor their
commitment as a delegate of the RO while also supporting legitimate privacy
interests of the RQ or the delegate of the RQ as well as jurisdictional
mandates that could force the RS to disregard a valid authorization token
("export restriction") or accept an authorization token that was not rooted
in trust of the AS ("break the glass").

To summarize, GNAP _should_ deal with delegation as distinct from
authorization. Some aspects of delegation _may_ be out of band for GNAP
because GNAP is an authorization protocol. The case of an authorization
token being part of a delegation chain _should not_ be precluded by GNAP.

The transport and API between a user agent and an AS and a user agent and
an RS are not a matter of authorization and, although critically important,
might not need to be specified by GNAP.

I've not used any SSI terminology above. Can you help me understand what
SSI, banking, or other use-cases I may be missing?

- Adrian

On Wed, Feb 24, 2021 at 8:15 PM Francis Pouatcha <[email-masked]> wrote:

> Justin, Adrian,
>
>
>
> in my initial contributions, I did refer to SSI just as a sample use case *user
> device generated* token. We have a lot of example out there running with
> Fido, EMV, electronic id cards, passports.
>
>
>
> Focus on the SSI philosophy might distract from the main issue: having *user
> device generated cryptograms*.
>
>
>
> A VC might be produced by an authority (let assume an AS) in a direct
> negotiation between RO and AS. No involvement of the Client.  I will call
> this a direct interaction.
>
>
>
> The VP is produced by the RO and presented to the Client. No involvement
> of the AS. This is also a direct interaction.
>
>
>
> The presentation of this original RO produced VP by a Client to an RS
> might require a new presentation produced by the Client and warping the
>  original VP. I call this an *embedded interaction*. I am missing this
> one in GNAP.
>
>
>
> The ‘*Embedded*’ suggestion did not make it pass the initial discussion,
> because we were unable to justify it legitime use to the OAuth legacy
> folks. We have been using this interaction mode in the banking world for
> the last 20 years through diverse protocols.
>
>
>
> Please to not talk about “*embedding user password*” a la “*password
> grant*”. I am referring to allowing a client carry a cryptogram produced
> by the RO to the RS.
>
>
>
> If we define the producer of the Token to be an AS, the we will have to
> show a mortal how to run the http based A-(Server) on the user device.
>
>
>
> Even if we narrow the definition of the AS to producing the VC and not the
> VP, we still have a problem, as some VC might be produced by the user.
>
>
>
> In the EU we will be witnessing eIDAS certificates issued to user,
> allowing them to produce their own VC, without the help of server based AS?
> Shall this make those VC producing applications running on the user device
> AS? Then we will have to redefine AS.
>
>
>
> /Francis
>
>
>
>
> *From:* Francis Pouatcha <[email-masked]>
> *Sent:* Thursday, February 25, 2021 1:13 AM
> *To:* Justin Richer <[email-masked]>; Adrian Gropper <
> [email-masked]>
> *Cc:* Francis Pouatcha <[email-masked]>; Denis <[email-masked]>;
> txauth gnap <[email-masked]>
> in my initial contributions, I did refer to SSI just as a sample use case *user
> device generated* token. We have a lot of example out there running with
> Fido, EMV, electronic id cards, passports.
>
>
>
> Focus on the SSI philosophy might distract from the main issue: having *user
> device generated cryptograms*.
>
>
>
> A VC might be produced by an authority (let assume an AS) in a direct
> negotiation between RO and AS. No involvement of the Client.  I will call
> this a direct interaction.
>
>
>
> The VP is produced by the RO and presented to the Client. No involvement
> of the AS. This is also a direct interaction.
>
>
>
> The presentation of this original RO produced VP by a Client to an RS
> might require a new presentation produced by the Client and warping the
>  original VP. I call this an *embedded interaction*. I am missing this
> one in GNAP.
>
>
>
> The ‘*Embedded*’ suggestion did not make it pass the initial discussion,
> because we were unable to justify it legitime use to the OAuth legacy
> folks. We have been using this interaction mode in the banking world for
> the last 20 years through diverse protocols.
>
>
>
> Please to not talk about “*embedding user password*” a la “*password
> grant*”. I am referring to allowing a client carry a cryptogram produced
> by the RO to the RS.
>
>
>
> If we define the producer of the Token to be an AS, the we will have to
> show a mortal how to run the http based A-(Server) on the user device.
>
>
>
> Even if we narrow the definition of the AS to producing the VC and not the
> VP, we still have a problem, as some VC might be produced by the user.
>
>
>
> In the EU we will be witnessing eIDAS certificates issued to user,
> allowing them to produce their own VC, without the help of server based AS?
> Shall this make those VC producing applications running on the user device
> AS? Then we will have to redefine AS.
>
>
>
> /Francis
>
>
>
>
>
> *From: *Justin Richer <[email-masked]>
> *Date: *Wednesday, February 24, 2021 at 1:58 PM
> *To: *Adrian Gropper <[email-masked]>
> *Cc: *Francis Pouatcha <[email-masked]>, Denis <[email-masked]>,
> txauth gnap <[email-masked]>
> *Subject: *Re: [GNAP] Integrating a GNAP AS with wallets and SSI
>
> +1 to this. In my opinion, building on anything other than HTTP right now
> is speculation, at best. And building an abstraction from zero-to-one
> concrete manifestations is a recipe for disaster. Once a second thing comes
> along, you inevitably realize that you put the abstraction points in the
> wrong place and have in fact baked in a lot of assumptions about your base
> case into what was supposed to be an abstraction layer.
>
>
>
> Instead, if there’s a desire to build out GNAP on top of other protocols,
> then it should be :translated: to those protocols. This happened with OAuth
> being built on top of COAP in ACE, without OAuth defining an abstraction
> layer ahead of time. And I’ll wager that if we had defined such a layer, it
> would not have considered things like the multi-tiered client structures
> that are in ACE, or the key distribution challenges in the IoT environment.
> Abstractions can come after the fact to aid future translations, but
> translation is nearly always more practical.
>
>
>
> But my point in starting this thread is that I think we can set up
> appropriate extension points for novel elements without throwing out the
> entire base protocol, or creating something overly abstract. So I think we
> can keep the “AS” component and the central HTTP-based protocol but have
> places where these other elements, like SSI wallets, can come in. I think
> we need to get away from the false conclusion that the SSI wallet has to
> :be: the AS. Instead, I think the SSI wallet can feed information into an
> AS in order for the AS to do its job.
>
>
>
>  — Justin
>
>
>
> - *Authorization:* The interaction protocols between the user agents of
> end users and servers
>
>
>
> Also, IMHO, SSI is not synonymous with protocols that presume a Holder as
> a mandated intermediary store for any attribute that moves between an
> issuer and a verifier. There are many, maybe most, use cases where SSI
> would be better served by control of the attribute over actual possession
> of the attribute.
>
>
>
> Adrian
>
>
>
>
>
>
>

---

From: Francis Pouatcha <[email-masked]>
Date: Thu, 25 Feb 2021 05:32:45 +0000

Adrian, inline,
I deeply want to understand what use-cases GNAP may be missing but I'm having trouble understanding your requirement and don't have the benefit of banking world experience. It doesn't matter to me whether GNAP is missing a use-case related to SSI or not. I just want to understand any limitations we might be building into GNAP 1.0

1. I think in terms of delegation. The GNAP AS is a delegate of the RO. The RO (or RQ) uses a user agent to interact with the AS. This user-agent could be a web browser or a mobile app. I assume that users can choose user agents that include a HSM such as a FIDO2 or SIM card and I hope that's encouraged but if an AS wants to deal with username / password, I would not prohibit that.

This is correct. What is we have a RO/RQ that doesn't need delegation? Delegation is only necessary is RO/RQ does not have the capability needed to the work. If RO/RQ can generate the token, we do not need to delegate to the AS.
2. The RS is another kind of delegation.
Yes. RS are delegate in that they manage resources on behalf of RO.

As with the AS, the RO can approach the RS directly with a user agent and exercise their privilege of specifying an AS as their delegate if the RS offers that feature. If the RS does not offer that feature to the RO, then I don't think GNAP is very relevant. If the RS restricts the RO's choice of ASs to a list or federation then GNAP still applies but in this case SSI principles are likely being trampled.
I do not understand the rest of this section. Seems out of scope.

3. The RQ relationship with the RS is _not_ delegation. It is authorization. This is true whether the RQ happens to be the RO or a separate party. I consider the RQ - RS relationship to be mediated by a Client, not a user agent.
This is what i call an embedded interaction. RQ signs a VP (containing an authorization - VC) and hand it over to the Client, so the client can use it to fetch a resource at the RS.

In some cases, the RQ user agent is also their client but I hope that GNAP never makes this assumption.
Yes. But in an abstract protocol flow, they should be represented as distinct roles.

In other words, the party that interacts with the AS may not be the same as the party that interacts with the RS because we want to encourage the ability for the RQ to delegate to another end user and the client of that end user. This is critical to effective workflows in the real world.

Dies delegation might be critical. I will skip it for now and stay focus on the core topic (direct & embedded interaction)

4. This raises issues around the responsibility of the RS to honor their commitment as a delegate of the RO while also supporting legitimate privacy interests of the RQ or the delegate of the RQ as well as jurisdictional mandates that could force the RS to disregard a valid authorization token ("export restriction") or accept an authorization token that was not rooted in trust of the AS ("break the glass").

Same as above, not relevant for this discussion.

To summarize, GNAP _should_ deal with delegation as distinct from authorization. Some aspects of delegation _may_ be out of band for GNAP because GNAP is an authorization protocol. The case of an authorization token being part of a delegation chain _should not_ be precluded by GNAP.

This is the core of what we shall be talking about and a very important point to be noted by the authors: auth vs. delegation. Nevertheless, GNAP IMHO is a grant negotiation protocol! If this is the case, direct and delegated authorizations must be addressed.

The transport and API between a user agent and an AS and a user agent and an RS are not a matter of authorization and, although critically important, might not need to be specified by GNAP.

If this is the case, GNAP will be very simple. Is this the case in the current draft?

I've not used any SSI terminology above. Can you help me understand what SSI, banking, or other use-cases I may be missing?

Let me bring the keywords and let web search do the work:
Banking:
  EBICS -> Protocol used in the banking world relying on public key crypto for the production and transport of authorizations. RO can sign a payment request and hands it over to a Client (Processor). Client will sign request and hand it over to the RS (bank). Bank will execute the RO payment request. This is an embedded interaction. No AS. Is there any Grant Negotiation? Not Sure. I think yes. Is this in the scope of GNAP? Not sure.

  EMV-Chip-Card (you are surely carrying one). RO (bearer) will put in the POS-device of the merchant (RQ). Smart card will sign a payment and hands over the cryptogram to the merchant device. Merchant device will send cryptogram to the card processor (Client). The Client will forward request to the RS (bank) for execution. Bank will confirm the payment.

SSI Wallet -> Self Sovereign Identity
  Maybe too new to be addressed. We might have some examples in the GNAP use case repository. A web search will give you better examples than what i can write here.

/Francis

On Wed, Feb 24, 2021 at 8:15 PM Francis Pouatcha <[email-masked]<mailto:[email-masked]>> wrote:

Justin, Adrian,

Let distinguish between:

/Francis

________________________________
From: Francis Pouatcha <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, February 25, 2021 1:13 AM
To: Justin Richer <[email-masked]<mailto:[email-masked]>>; Adrian Gropper <[email-masked]<mailto:[email-masked]>>
Cc: Francis Pouatcha <[email-masked]<mailto:[email-masked]>>; Denis <[email-masked]<mailto:[email-masked]>>; txauth gnap <[email-masked]<mailto:[email-masked]>>
Subject: Re: [GNAP] Integrating a GNAP AS with wallets and SSI

Justin, Adrian,

Let distinguish between:

/Francis

From: Justin Richer <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, February 24, 2021 at 1:58 PM
To: Adrian Gropper <[email-masked]<mailto:[email-masked]>>
Cc: Francis Pouatcha <[email-masked]<mailto:[email-masked]>>, Denis <[email-masked]<mailto:[email-masked]>>, txauth gnap <[email-masked]<mailto:[email-masked]>>
Subject: Re: [GNAP] Integrating a GNAP AS with wallets and SSI

 — Justin

Adrian

IF

THEN

  *   roles
  *   entities
  *   relationships

BTW

THEN

END IF

/Francis

Hi  Justin,

Denis

 — Justin

Hi Torsten,

Continuing your quote:

Adrian

?

best regards,

Torsten.

Adrian

Justin,

 — Justin

Thanks,

Tobias Looker

Mattr

+64 (0) 27 378 0461

Hi Justin,

Cheers

Fabien

 — Justin

---

From: David Waite <[email-masked]>
Date: Wed, 24 Feb 2021 23:09:47 -0700

> On Feb 24, 2021, at 6:14 PM, Francis Pouatcha <fpo=[email-masked]> wrote:

> A VC might be produced by an authority (let assume an AS) in a direct negotiation between RO and AS. No involvement of the Client.  I will call this a direct interaction.

1. If I understand correctly, this is talking about the resource owner as if it were participating as a client which can negotiate receiving a verifiable credential as a type of non-delegated authorization token. This should probably be a distinctly named role in this sort of protocol like “holder” or “wallet”. I’ll pick holder.

> The VP is produced by the RO and presented to the Client. No involvement of the AS. This is also a direct interaction.

2. So in this case the holder is presenting a token to the client, so the holder is acting as a client and the “Client” is acting as GNAP resource server. The token is manipulated by  in some manner and being given as a verifiable presentation which will act as delegated authorization

> The presentation of this original RO produced VP by a Client to an RS might require a new presentation produced by the Client and warping the  original VP. I call this an embedded interaction. I am…

3. And now the “Client”, is acting as a client, trying to get a piece of software (possibly an AS - possibly a _different_ AS from #1) to translate the VP to a token format that the desired ultimate RS will consume

If I understand all of this correctly, the issue is that the verifiable presentation given to the client needs to actually be a verifiable credential issued by the holder to represent the delegation and to give the client something they are able to present to others. I suspect this is a cryptographic protocol issue and not a network protocol one, where the VC/VP proof mechanism needs to allow for delegation.

> The ‘Embedded’ suggestion did not make it pass the initial discussion, because we were unable to justify it legitime use to the OAuth legacy folks. We have been using this interaction mode in the b…

The problem is that the proof on a VP is not universally valid for all presentation proofs. The proof may _only_ be verifiable by the client, and not to an AS or RS that it is later echoed to. 

> Please to not talk about “embedding user password” a la “password grant”. I am referring to allowing a client carry a cryptogram produced by the RO to the RS.

Indeed an AS is not needed for this - you just need delegatable credentials :-)

The AS is similar to what Microsoft used to refer to as a Security Token Service (STS) - it is something that consumes tokens from parties it trusts and emits tokens that other parties trust. “Token” may be an abstract security check - a username/password form and consent dialog might qualify as a “token” that can be consumed.

The AS serves as a concentration point of business logic concerns and policy in many deployments - rather than have many RSes know how to do things like verify the user’s authentication and capture consent, a single AS does that. Likewise, the tokens which are emitted could be in a complex format like JSON-LD and ZKP proofs - or could be in a very optimized format where policy decisions have already been made for the RSes.

In the sense of an STS, it makes sense for the AS to issue a VC to a holder has attributes representing system capabilities that the user is allowed to delegate. It also makes sense for the STS to take a presentation of a credential representing user granted capabilities to a client, validate it, and translate that to a format that a RS might prefer to consume like a JWT access token.

> If we define the producer of the Token to be an AS, the we will have to show a mortal how to run the http based A-(Server) on the user device.

There are lots of ways to get valid tokens other than OAuth, OpenID Connect, and GNAP. But per the STS description above, is is unlikely an RS would choose to trust an AS hosted on a user’s device.

>  Even if we narrow the definition of the AS to producing the VC and not the VP, we still have a problem, as some VC might be produced by the user.

I don’t quite understand this - what purpose would the AS have to produce VPs in these scenarios. I would assume a VP from the AS would be asserting the AS as the subject, not a subject of any of the other roles.
 
> In the EU we will be witnessing eIDAS certificates issued to user, allowing them to produce their own VC, without the help of server based AS? Shall this make those VC producing applications runnin…

I would assume these are delegatable credentials.

However, I would expect that many parties would not want to make a trust decision based on that credential (was the user really allowed to delegate this responsibility to another party? Have I authenticated this party? Can I track this party if they are abusing the system? How do I know if the capabilities that the user has delegated are even capabilities the user is authorized to?… and do I really have to do all of this evaluation on every single network request?) . An AS could request a presentation, evaluate all of that policy, and issue a token that a RS would consume.

-DW