User choice and consent, and user notice

[Denisthemalice]

In the current draft, a user consent phase is only considered to take place at the (single) AS.

However, as soon as a RS is trusting more than one AS, the end-user must be able to make at least an AS(s) choice before contacting any AS.

When a client attempts to perform on operation on a resource and when that resource is protected, that operation may be denied either because the resource is protected using an authentication mechanism or because the resource is protected using some form(s) of access token(s). For the requested operation on the requested object, the RS should be able to indicate, if it wishes to do so, which authentication mechanism(s) may be used or which privileges are required for each AS.

When some privileges issued by some AS(s) are required, the information that MAY be returned will be a combination of AS URLs (using OR or/and AND operators) and for each AS either which attributes types (and possibly values) are required or which RO associated with an AS is recognized to issue a capability for that operation on that object.

Before making its choices, the end-user should be able to be informed of the reasons or the rational for each privilege before requesting one or more access tokens: this step is called user notice.

This means that every end-user should have the ability to agree about the rights and/or the attributes types and values he accepts to be placed into one or more access tokens.

The User choice and consent, as well as the user notice should be made available in the preferred language of the end-user.

These two steps which are fundamental from a privacy point of view are currently unsupported/missing in the draft.

[jricher]

Within a given request, there is a single AS. The fact that an RS might have other AS's that it also trusts is irrelevant to the protocol. The client will not talk to multiple AS's to get a single access token, just one.

Furthermore, it will usually be the case that neither the user nor the RO have any say over which AS a given RS will trust. The RS should have choice, but that choice isn't necessarily extended to the user.

[agropper]

If GNAP access tokens are to be compatible with capabilities then we cannot presume a relationship between RS and AS at all. The RS issues a capability and promises to honor it or an attenuated version of it when it is presented at some future time. The RS trusts itself.

The AS is the role that processes a request to issue a (attenuated) version of a capability that it has. The issuance and attenuation decision is based on the request and policies applicable to the request.

The RS had its say when it issued the capability. After that, the scope of access can only be equal or less to what the RS issued.

Any trust relationship between the AS and the RS needs to be optional as far as GNAP is concerned lest we break the capabilities model.

Adrian

On Fri, Mar 12, 2021 at 2:59 PM Justin Richer @.***> wrote:

Within a given request, there is a single AS. The fact that an RS might have other AS's that it also trusts is irrelevant to the protocol. The client will not talk to multiple AS's to get a single access token, just one.

Furthermore, it will usually be the case that neither the user nor the RO have any say over which AS a given RS will trust. The RS should have choice, but that choice isn't necessarily extended to the user.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/215#issuecomment-797720549, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YMC2NHLUWM47YNLRKTTDJP7ZANCNFSM4ZCYQE7Q .

[fimbault]

We should review the trust boundaries in detail, but I had a simple view in mind regarding "capabilities", that the current GNAP request allows. The AS is able to issue access tokens with rights (actions) , that's basically your capabilities (attenuation is not being supported right now, could be if we don't restrict to jwt).

A complementary feature (not covered currently by GNAP) would be that the AS issues access tokens with pure attributes (ex roles), that can be used in the RS works with ACLs/rbac/abac.

A priori what you're saying includes more assumptions on the architecture than what I just described, and even if framed slightly in a different angle is not very far away from Denis' point of view (with having a sort of preflight focused on the RS), as far as I understand it. My view is that might be an option/extension. Or am I misunderstanding? That's an interesting discussion to have anyways.

+1 with what @jricher said on multiple ASs as well. We need to keep the model simple, and it's not obvious what we'd gain by mixing. We can always make distinct requests to issue each a token to their favorite AS if needed.

[agropper]

@fimbault I defer to the capabilities experts, but my understanding is that a capability has to be issued by the server that will be asked to enforce it. If that is not the case, then GNAP needs to have what UMA calls a "registration" phase 1 where the AS and RS are introduced in order to establish a trust relationship such as storing the public key of the AS. This is effectively an ACL architecture where the RS associates some privileges with the identity of the AS.

I'm OK with GNAP supporting both the two-phase (ACL) and one-phase (capabilities) model as long as we don't introduce human right to privacy traps in the process. I make this proposal in the thread "GNAP Architecture and the role of the AS". @jricher suggested it would be easier to reach consensus if I presented a use-case without trying to fit it into our current role definitions. I agree with him.

I also +1 @jricher desire to avoid multiple ASs. This leads me to the conclusion that the AS is the place where a request is processed into a token. Some architectures try to split the PDP into a component that holds the policies and a separate component that receives the requests. This is a privacy harm from my perspective because it exposes the request to both sides of the split. In this split design I would say the AS is the role that holds the policies and the role that initially receives the request is just a mediator trusted by the AS but with no real authorization power.

A mediator role does add privacy to the design as it reduces the opportunity for correlation across request transactions. This is good. However, the mediator must not be privy to contents of the request. The request should be encrypted to the AS. This idea might be what @jricher is introducing in that thread he started as "GNAP Architecture and the role of the AS".

[fimbault]

Yes you're right about capabilities, if you want to support them in full, you need a RS preflight (cf discussion on HTTP headers), which very well could be an optional component too.

A second optional component could be a about the interaction, as suggested by Justin. Possibly with some RS hiding there.

So it makes sense to discuss practical use cases on the ML and see up to where we can get.

[jricher]

The interaction component could be hosted by the party that runs the RS, separate from the party that runs the AS. GNAP actually gives us a change to do that in a way that OAuth and UMA don't. Introducing the RS and AS to each other should be independent of the score protocol, like it is in UMA2 (which split this into a separate spec), but we've got the start of it in the "Resource Servers" section in GNAP right now. We've got a big advantage in GNAP's core design in that

But we need to keep in mind that if we make this more complicated for other extremely common use cases (user == RO, RS and AS are tightly coupled, token is a reference key to a DB lookup, etc) then most developers simply won't care about the advanced stuff. GNAP has an opportunity to be a security protocol that can function across this spectrum in a consistent and reasonable way.

[agropper]

+1 @jricher It's taken me years to almost understand capabilities and GNAP may not be the place to teach that. The trick is to harmonize our protocol with the SSI data models and the overall innovation of keeping federation out of the core.

[fimbault]

I believe attributes and rights (already in our definitions) are a much simpler concept to grasp (plus that may depend on how that's deployed, that's why I think we shouldn't include discussions on ACLs vs capabilities, cf #214)

[smartopian]

+1 to @Denisthemalice

• the notice has legally required fields needed for processing of personal data, without it, the systems has a had time transferring liability across legal and technical domains with thinks like DiD's. (e.g. low vectors of interoperability)

  The interaction component we recommend is the semantic notice receipt framework. This is the update from the (now 6 year old Consent receipt generator spec), The Notice receipt framework is usable for any legal justification for identity management systems.

  The core notice receipt, provides all the required information for binding the legal roles and control scopes to an identity protocol for the RS and AS to use, GNAP, or UMA, Federated Id etc. It also provides the policy framework for identity scheme operators to be embeded in the processing.

Not to mention transparency to people (which is legally required) To go beyond a service USER to a legal data subject - aka Human with identity authority) a subjectid is misleading as its not a legal field or representation of a person, its a system user (could be anything - big cyber gap).

To bind the person to a sub_id it requires legal. notice. Which is why a notice receipt framework for purpose driven service architectures to do binding is I recommend for active state input and extending interoperability. A key feature of a notice receipt, is its use to - provide proof of notice when processing personal data based on digital identifiers.

Proof of notice. Binding a token to a notice receipt is a large part of what we are working on in ANCR - WG at the Kantara Initiative now. -- This is apart of finishing the receipt generator work for ISO 27560 and 29184, (these international identity governance standards provide a great (only) way to bind scopes (e.g. Consent to User Permissions) for user controlled data portability and data sharing.

[agropper]

@smartopian I have a hard time mapping the legal and jurisdictional constraints to an abstract architecture, particularly when we are in the midst of changing core definitions for roles and actors in GNAP.

We have at least one ML thread built around a use-case which is specified in terms of US law / HIPAA regulations. https://mailarchive.ietf.org/arch/msg/txauth/FPIrji3uAQDLkGtqVvC-PreMWbI/

If that thread doesn't helps us to understand your point, could you can start another use-case thread on the ML?

[smartopian]

AH, I did take a few big leaps,

To rewind a little - and comment directly to @Denisthemalice, I think this thread raises a few very interesting points,

"For the requested operation on the requested object, the RS should be able to indicate, if it wishes to do so, which authentication mechanism(s) may be used or which privileges are required for each AS."

• A notice receipt from the RS would be provide this information and its payload is are purpose and scopes of use, to semantically wrap and contain the payload of identifiers and any associated data.

"When some privileges issued by some AS(s) are required, the information that MAY be returned will be a combination of AS URLs (using OR or/and AND operators) and for each AS either which attributes types (and possibly values) are required or which RO associated with an AS is recognized to issue a capability for that operation on that object."

• my comment: this is purpose specified (and a component of any notice) the physical, legal infrastructure for all of this exists already

"Before making its choices, the end-user should be able to be informed of the reasons or the rational for each privilege before requesting one or more access tokens: this step is called user notice."

• yes, but i argue here, that this accomplished at a higher level of abstrction, earlier in the flow, where this is inherited and only needs an active state.
• and / or - the system (rather than a person) could be informed of the purpose and it shall have a code of practice around the operation of an access token (aka a identity governance scheme the PII Controller is operating) [which is effectively enforced regulation and standards] and communicated with a receipt. (ML and HL)

"This means that every end-user should have the ability to agree about the rights and/or the attributes types and values he accepts to be placed into one or more access tokens." - yes -- but also inherited from a higher level of abstraction, based on purpose and what is expected, (aka the contextual/physical norm

---

To you Mr Gropper, There is a legal requirement in all use cases for a notice of processing, (its not abstract) most of the times it is in a back channel, a discontected non operational static policy, that hasn't scaled. (and is not functional).

This is although an issue, especially with SSI/ ToiP . SSI generally aims/claims to provide framework for ( independent of a federation ) identity management. To be usable across technical and legal domains, means the identity governance components need to also be a part of the use of the DiD's etc. or arguably its not SSI or legal, and definitely not legally usable across identity ecosystems. So, perhaps take your thread on changing core GNAP definitions to a new thread.

Happy to chat with you/anyone about notice and semantic governance work at Kantara and ISO how it is extended by the W3C DPV, (data privacy vocabulary ontology) which is something like ML.

if you want to know more? you can also check out the ISWG Notice & Consent task force in ToiP, we are walk thing through the legal and technical semantics of decentralized data and identity governance schemes for SSI. (updated glossary coming soon)

[jricher]

In a lot of use cases, the legal relationships between the parties running/owning the client instance, the AS, and the RS are established out of band. And in many cases, there is no assumption of a legal binding between an identifier as presented in this spec and any real-world person entity.

I can see how a consent receipt data structure could be carried alongside the identifiers, assertions, and access tokens that come back from the AS, and it would be an interesting extension to explore.

[Denisthemalice]

@smartopian I am not advocating the need of a "Consent receipt", but simply the need for a User choice and consent, and a user notice.

To draw a parallel: Since the publication of the EU GDPR (General Data Protection Regulation) the use of the cookies has changed. An end-user is allowed to accept them all, to deny them all (except functional cookies) and even to make some choices. The end-users can know which legal entity will collect the cookies and what for.

The same kind of screens should be proposed to the end-user.

From a technical perspective, specific end-points should be defined and used, since this kind of dialog is not done using APIs.

[Denisthemalice]

@jricher. You wrote:

In a lot of use cases, the legal relationships between the parties running/owning the client instance, the AS, and the RS are established out of band. And in many cases, there is no assumption of a legal binding between an identifier as presented in this spec and any real-world person entity.

This does not mean that in all use cases, the trust relationships (and NOT the legal relationships which are out of the scope of the draft) between the AS and the RS are established out of band. The very first User consent and choice for an end-user should be to agree to ask for an access token for some reason(s). If these reason(s) seem acceptable by the end-user, then the client will contact one or more ASs and then will request access tokens from these ASs.

@jricher. You wrote:

I can see how a consent receipt data structure could be carried alongside the identifiers, assertions, and access tokens that come back from the AS, and it would be an interesting extension to explore.

The User Consent and choice as well as the User Notice phase must appear before contacting any AS and hence before requesting access tokens.

[smartopian]

Hi Denis,

Interesting you bring up cookies, which is really not consent at all. Its identifier surveillance, and notice is at the attribute level rather than at the purpose level. The master identity controller / person is providing a social/legal permission called consent, which is converted into a signal in a permission framework, called cookie notice.

In our framework, a person can make a notice receipt for a website, that shows all the cookies and identifiers, then uses this receipt to request the legal control of that identifier. Or to block the use of the surveillance the identifier provides.

The screens you mention to the end user are permission screens, and the screens we advocate for - at the outset (prior to identifier surveillance) are 2 Factor Consent Notices, one for notice of risk linking the physical device and system to context of use on a webpage, and then the second notice to a person, which would then be agreed to provide a proof of notice receipt to the controller and a consent receipt to the person.

The legally standardized semantics and ontology used in a notice receipt can be used to provide active state and context to GNAP, and enable dynamic controls and permissions. (Which is where all the fun stuff really happens) With active state identity transparency and privacy for advanced identity protocols like GNAP.

If a receipt has key management and a digital counter part, then it becomes a consent token - the providence of the verified organizations are used to transport and identify the purpose of use, to which the human has rights to control processing. How the identity protocol and systems manages this can be externally monitored and its performance captured and compared to the next service, using privacy law and standards.

(o address this - I recommend using Active State Transparency tools like the notice and consent receipt (spec update coming soon and will be send here to GNAP for review)

Best,

• Mark,

On Mar 24, 2021, at 6:59 AM, Denisthemalice @.**@.>> wrote:

@smartopianhttps://github.com/smartopian I am not advocating the need of a "Consent receipt", but simply the need for a User choice and consent, and a user notice.

To draw a parallel: Since the publication of the EU GDPR (General Data Protection Regulation) the use of the cookies has changed. An end-user is allowed to accept them all, to deny them all (except functional cookies) and even to make some choices. The end-users can know which legal entity will collect the cookies and what for.

The same kind of screens should be proposed to the end-user.

From a technical perspective, specific end-points should be defined and used, since this kind of dialog is done done using APIs.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/ietf-wg-gnap/gnap-core-protocol/issues/215#issuecomment-805724825, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABR6VZ52BFO4ICSSRWZYCODTFHAXVANCNFSM4ZCYQE7Q.

[Denisthemalice]

@jricher : Would you be able to respond to @smartopian arguments and to my arguments ?

[jricher]

The types of notice and consent described here are preconditions to the application of a delegation protocol like GNAP -- GNAP presumes that the decisions surrounding the resources at the RS and available rights at the AS have already happened before the client can be issued a token. This is discussed further in the trust relationships section: https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-07.html#name-trust-relationships