Privacy considerations

[fimbault]

We need to take privacy as a pillar of GNAP

• 74

• Interact Server

[fimbault]

Regarding IS : proposed definition

Interaction Server (IS): component from the AS or dedicated server interfacing with an AS, that manages the front-end interactions with a RO, in order to gather its authorization. Note : the IS is an optional component.

[Denisthemalice]

The issue #234 has been closed in less than 24 hours because it had the same title, but contained rather different topics.
Text is still needed for the "Privacy Considerations" section.

I proposed two lines to address two different topics. One is centered on the end-user while the other one is centered on the AS.

Some comments have been made on the first topic, without giving a rational, while no comment has been done on the second topic.

Proposed additional text:

Some end-users care about their privacy. When tokens are considered to be opaque for the clients, end-users are not supposed to know which privileges (rights and/or attributes) have been placed inside an access token by an AS.

ASs play a central role by delivering access tokens to clients. When an AS delivers rights to a client (and hence to an end-user), it is in a position to know and to log which method(s) is/are likely to be performed by an end-user on some object(s) on a RS.

[agropper]

The end user is accountable for the request it makes at an AS. The end user is accountable for the information it accesses at at the RS. For example, the request might make identity claims and purpose claims as well as suggest a scope of resources sought. From my privacy perspective, the end-user is not liable for whatever scope is granted to them. That was entirely on the AS and if the AS makes an error then too bad for them.

The AS can decide to verify the identity claims presented by the request. If the AS does an inadequate verification job, then again, it's the AS problem and too bad for them.

Lastly, we have the purpose claims of the end-user. Here, the AS has no direct verification path. What the AS needs is an audit mechanism. To enable that, the AS would need to have the request notarized and logged by an independent party (the notary) so that in the event the purpose is breached a court order could yield evidence via the log that the request included the particular purpose claims.

The notary could be the AS themselves if the log were clearly contemporaneous and secure - on a public ledger, for example.

All of this seems essential but outside the core GNAP protocol to me.

[Denisthemalice]

@agropper. I failed to understand how your comment might relate to this thread which is attempting to produce text to be inserted in the Privacy Considerations section.

[agropper]

@Denisthemalice The core privacy consideration is maximum agency for the resource owner. Maximizing their agency means giving them: 1 - the power to delegate authorization to an agent they control (automation) 2 - not having to share policies or otherwise explain "why" an authorization decision was made (sovereignty) 3 - data minimization with respect to what other parties get to see or understand about an authorization request (minimization)

1, 2, and 3 are the core. They are defined in terms of a resource owner, an authorization request, and an authorization decision. Everything else is optional or an extension to GNAP. Conversely, taking away either automation, sovereignty, or minimization reduces the privacy of the resource owner and breaks GNAP by launching an explosion of complexity as the resource owner seeks to protect their privacy.

[IDmachines]

Maximum agency requires not of risk or there is no validity to the agency.

This is the two-factor consent mark is referring to, being meaningful notice of risk, followed by meaningful consent (not consent management, or agreement to privacy policy as these are RS functions and not related to the RO agency.)

From: Adrian Gropper @.> Sent: Saturday, April 3, 2021 7:08 AM To: ietf-wg-gnap/gnap-core-protocol @.> Cc: Subscribed @.***> Subject: Re: [ietf-wg-gnap/gnap-core-protocol] Privacy considerations (#133)

@Denisthemalice https://github.com/Denisthemalice The core privacy consideration is maximum agency for the resource owner. Maximizing their agency means giving them: 1 - the power to delegate authorization to an agent they control (automation) 2 - not having to share policies or otherwise explain "why" an authorization decision was made (sovereignty) 3 - data minimization with respect to what other parties get to see or understand about an authorization request (minimization)

1, 2, and 3 are the core. They are defined in terms of a resource owner, an authorization request, and an authorization decision. Everything else is optional or an extension to GNAP. Conversely, taking away either automation, sovereignty, or minimization reduces the privacy of the resource owner and breaks GNAP by launching an explosion of complexity as the resource owner seeks to protect their privacy.

— 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/133#issuecomment-812850289 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHY7PYLUZSEIUY46U5R2A3TG3ZKVANCNFSM4UKXPLUA . https://github.com/notifications/beacon/AAHY7P5NEB43COMFO2C2BSLTG3ZKVA5CNFSM4UKXPLUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGBZRY4I.gif

[IDmachines]

Apologies for the edit, that was “requires” notice of risk.

From: Salvatore DAgostino Sent: Saturday, April 3, 2021 11:19 AM To: ietf-wg-gnap/gnap-core-protocol @.>; ietf-wg-gnap/gnap-core-protocol @.> Cc: Subscribed @.***> Subject: RE: [ietf-wg-gnap/gnap-core-protocol] Privacy considerations (#133)

Maximum agency requires not of risk or there is no validity to the agency.

This is the two-factor consent mark is referring to, being meaningful notice of risk, followed by meaningful consent (not consent management, or agreement to privacy policy as these are RS functions and not related to the RO agency.)

From: Adrian Gropper @. @.> > Sent: Saturday, April 3, 2021 7:08 AM To: ietf-wg-gnap/gnap-core-protocol @. @.> > Cc: Subscribed @. @.> > Subject: Re: [ietf-wg-gnap/gnap-core-protocol] Privacy considerations (#133)

@Denisthemalice https://github.com/Denisthemalice The core privacy consideration is maximum agency for the resource owner. Maximizing their agency means giving them: 1 - the power to delegate authorization to an agent they control (automation) 2 - not having to share policies or otherwise explain "why" an authorization decision was made (sovereignty) 3 - data minimization with respect to what other parties get to see or understand about an authorization request (minimization)

1, 2, and 3 are the core. They are defined in terms of a resource owner, an authorization request, and an authorization decision. Everything else is optional or an extension to GNAP. Conversely, taking away either automation, sovereignty, or minimization reduces the privacy of the resource owner and breaks GNAP by launching an explosion of complexity as the resource owner seeks to protect their privacy.

— 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/133#issuecomment-812850289 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHY7PYLUZSEIUY46U5R2A3TG3ZKVANCNFSM4UKXPLUA . https://github.com/notifications/beacon/AAHY7P5NEB43COMFO2C2BSLTG3ZKVA5CNFSM4UKXPLUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGBZRY4I.gif

[agropper]

I don't understand. Notice by whom to whom (in terms of my example)?

Adrian

On Sat, Apr 3, 2021 at 11:20 AM IDmachines @.***> wrote:

Apologies for the edit, that was “requires” notice of risk.

From: Salvatore DAgostino Sent: Saturday, April 3, 2021 11:19 AM To: ietf-wg-gnap/gnap-core-protocol @.>; ietf-wg-gnap/gnap-core-protocol @.> Cc: Subscribed @.***> Subject: RE: [ietf-wg-gnap/gnap-core-protocol] Privacy considerations (#133)

Maximum agency requires not of risk or there is no validity to the agency.

This is the two-factor consent mark is referring to, being meaningful notice of risk, followed by meaningful consent (not consent management, or agreement to privacy policy as these are RS functions and not related to the RO agency.)

From: Adrian Gropper @. @.> > Sent: Saturday, April 3, 2021 7:08 AM To: ietf-wg-gnap/gnap-core-protocol @. @.> > Cc: Subscribed @. @.> > Subject: Re: [ietf-wg-gnap/gnap-core-protocol] Privacy considerations (#133)

@Denisthemalice https://github.com/Denisthemalice The core privacy consideration is maximum agency for the resource owner. Maximizing their agency means giving them: 1 - the power to delegate authorization to an agent they control (automation) 2 - not having to share policies or otherwise explain "why" an authorization decision was made (sovereignty) 3 - data minimization with respect to what other parties get to see or understand about an authorization request (minimization)

1, 2, and 3 are the core. They are defined in terms of a resource owner, an authorization request, and an authorization decision. Everything else is optional or an extension to GNAP. Conversely, taking away either automation, sovereignty, or minimization reduces the privacy of the resource owner and breaks GNAP by launching an explosion of complexity as the resource owner seeks to protect their privacy.

— 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/133#issuecomment-812850289> , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AAHY7PYLUZSEIUY46U5R2A3TG3ZKVANCNFSM4UKXPLUA> . < https://github.com/notifications/beacon/AAHY7P5NEB43COMFO2C2BSLTG3ZKVA5CNFSM4UKXPLUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGBZRY4I.gif>

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/133#issuecomment-812879510, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YIY6SV6U6PF5D5LIS3TG4W4HANCNFSM4UKXPLUA .

[IDmachines]

Notice of the identity management systems surveillance risk (AS, RS and clients)

So, how can the AS convey to the RO the risk?

From: Adrian Gropper @.> Sent: Saturday, April 3, 2021 12:02 PM To: ietf-wg-gnap/gnap-core-protocol @.> Cc: Salvatore DAgostino @.>; Comment @.> Subject: Re: [ietf-wg-gnap/gnap-core-protocol] Privacy considerations (#133)

I don't understand. Notice by whom to whom (in terms of my example)?

Adrian

On Sat, Apr 3, 2021 at 11:20 AM IDmachines @. <mailto:@.> > wrote:

Apologies for the edit, that was “requires” notice of risk.

From: Salvatore DAgostino Sent: Saturday, April 3, 2021 11:19 AM To: ietf-wg-gnap/gnap-core-protocol @. <mailto:@.> >; ietf-wg-gnap/gnap-core-protocol @. <mailto:@.> > Cc: Subscribed @. <mailto:@.> > Subject: RE: [ietf-wg-gnap/gnap-core-protocol] Privacy considerations (#133)

Maximum agency requires not of risk or there is no validity to the agency.

This is the two-factor consent mark is referring to, being meaningful notice of risk, followed by meaningful consent (not consent management, or agreement to privacy policy as these are RS functions and not related to the RO agency.)

From: Adrian Gropper @. <mailto:@.> @. <mailto:@.> > > Sent: Saturday, April 3, 2021 7:08 AM To: ietf-wg-gnap/gnap-core-protocol @. <mailto:@.> @. <mailto:@.> > > Cc: Subscribed @. <mailto:@.> @. <mailto:@.> > > Subject: Re: [ietf-wg-gnap/gnap-core-protocol] Privacy considerations (#133)

@Denisthemalice https://github.com/Denisthemalice The core privacy consideration is maximum agency for the resource owner. Maximizing their agency means giving them: 1 - the power to delegate authorization to an agent they control (automation) 2 - not having to share policies or otherwise explain "why" an authorization decision was made (sovereignty) 3 - data minimization with respect to what other parties get to see or understand about an authorization request (minimization)

1, 2, and 3 are the core. They are defined in terms of a resource owner, an authorization request, and an authorization decision. Everything else is optional or an extension to GNAP. Conversely, taking away either automation, sovereignty, or minimization reduces the privacy of the resource owner and breaks GNAP by launching an explosion of complexity as the resource owner seeks to protect their privacy.

— 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/133#issuecomment-812850289> , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AAHY7PYLUZSEIUY46U5R2A3TG3ZKVANCNFSM4UKXPLUA> . < https://github.com/notifications/beacon/AAHY7P5NEB43COMFO2C2BSLTG3ZKVA5CNFSM4UKXPLUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGBZRY4I.gif>

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/133#issuecomment-812879510, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YIY6SV6U6PF5D5LIS3TG4W4HANCNFSM4UKXPLUA .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/133#issuecomment-812885262 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHY7P2XO5MPGCSNM36HO3DTG43Y5ANCNFSM4UKXPLUA . https://github.com/notifications/beacon/AAHY7P5J6DPZZI3AHH5XOPTTG43Y5A5CNFSM4UKXPLUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGBZ2KDQ.gif

[agropper]

I'm sorry, @IDmachines, I really don't understand your perspective. Here's my use-case https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/133#issuecomment-812651001 There's no identity management system that I can see. The RO delegates to an AS that they control. The AS receives requests with claims that may be related to an identity management system but that has nothing to do with GNAP as far as I can tell. Nobody forces the requesting party to produce any particular claims when making a request. Nobody forces the AS to verify the claims.

What am I missing?

[agropper]

If, @IDmachines, your implication is that the AS is not owned or otherwise controlled by the RO, then that's a different use-case that I might call "turtles all the way down". I consider any AS that is not an agent of the RO as an agent of the RS or some flavor of data broker. It certainly does compromise the RO's privacy just as it dilutes their agency. This is the why I work to make sure GNAP does not make this the core. It would be a privacy disaster.

[IDmachines]

Hi @agropper, yes that was curt, let me try to do better.

"The end user is accountable for the request it makes at an AS. "

In order for there to be accountability the "end user" <- hate the term. has to be aware of the risks (identity, surveillance, security, privacy) before she makes the request.

Same for the RO especially when they delegate.

Same has to be true for all actors.

Isn't all of this identity management?

@idmachines

IDmachines

1264 Beacon St., #5

Brookline, MA 02446

+1 617.201.4809

https://idmachines.com

@idmachines

---

From: Adrian Gropper @.> Sent: Saturday, April 3, 2021 1:32:45 PM To: ietf-wg-gnap/gnap-core-protocol @.> Cc: Salvatore DAgostino @.>; Mention @.> Subject: Re: [ietf-wg-gnap/gnap-core-protocol] Privacy considerations (#133)

I'm sorry, @IDmachines https://github.com/IDmachines , I really don't understand your perspective. Here's my use-case #133 (comment) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/133#issuecomment- 812651001 There's no identity management system that I can see. The RO delegates to an AS that they control. The AS receives requests with claims that may be related to an identity management system but that has nothing to do with GNAP as far as I can tell. Nobody forces the requesting party to produce any particular claims when making a request. Nobody forces the AS to verify the claims.

What am I missing?

- You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/133#issuecomment- 812898335 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHY7PZIO4W2A5NMFBSEPILTG 5GL3ANCNFSM4UKXPLUA . https://github.com/notifications/beacon/AAHY7P2GJQISASLLWEQ624LTG5GL3A5CNFS M4UKXPLUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGBZ5QHY .gif

[IDmachines]

@agropper thanks

I think that even in the case where its controlled by the RO there is inherently some (across the ISSP layers) risk in sharing anything with the AS, its transparency about the initial risk conditions that I (and Mark) are driving at, and these are the privacy considerations that we are trying to include.

Best /s

From: Adrian Gropper @.> Sent: Saturday, April 3, 2021 1:42 PM To: ietf-wg-gnap/gnap-core-protocol @.> Cc: Salvatore DAgostino @.>; Mention @.> Subject: Re: [ietf-wg-gnap/gnap-core-protocol] Privacy considerations (#133)

If, @IDmachines https://github.com/IDmachines , your implication is that the AS is not owned or otherwise controlled by the RO, then that's a different use-case that I might call "turtles all the way down". I consider any AS that is not an agent of the RO as an agent of the RS or some flavor of data broker. It certainly does compromise the RO's privacy just as it dilutes their agency. This is the why I work to make sure GNAP does not make this the core. It would be a privacy disaster.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/133#issuecomment-812899660 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHY7P7XENNMSW7QIVB3IALTG5HQHANCNFSM4UKXPLUA . https://github.com/notifications/beacon/AAHY7P3RJZJDOFIZ4SM3GKTTG5HQHA5CNFSM4UKXPLUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGBZ52TA.gif

[agropper]

Now I get it @IDmachines. We're talking past each other because I'm doing everything I can to keep GNAP away from identity and you're linking identity to accountability. We might be in violent agreement.

I want auditability and accountability at the core of the protocol as much as anyone. So I start with self-sovereign decentralized identifiers that can be used for non-repudiable signatures independent of any particular trust framework. I then presume self-sovereign semi-autonomous agents delegated by that self-sovereign identifier. Where shared storage services are concerned, I try to put as much as possible into W3C/DIF "Encrypted Data Vaults" where the service provider has no responsibility for the contents, privacy, and much of security (because everything is encrypted, including the indexes, and they don't hold the keys). In my world-view, that leaves the service providers that do have access to unencrypted data, the GDPR processors, the GNAP Resource Servers. I assume they are hostile and that I, as an RO, am forced to deal with them anyway.

In my self-sovereign fantasy world GNAP does allow for notaries that can act as a third party to countersign artifacts and keep logs that can only be accessed by court order. When any two parties RO - RS, RO - AS, end-user-RS, end-user-AS interact and don't trust each other, I assume they will get the transaction notarized, which includes a log accessible during dispute. I don't think notarization will be be in GNAP core, but it must be accessible in cases where the various self-sovereign end-users don't trust each other.

[IDmachines]

Thanks @agropper we should have a notary conversation outside this thread/RFC as we agree that is critical, but maybe we see some different use cases. Again, ones that occur prior to some of the flows you rightfully point out. /s

[jricher]

Subject identifier privacy considerations discussed in #249

[aaronpk]

We now have a Privacy Considerations section in draft -07. Closing this issue, but feel free to open new issues if there are new considerations not yet discussed.