The first figure in section 1.4 should be split and revisited

[Denisthemalice]

The text indicates :

"For example, for a client instance interested in only getting subject information directly, and not calling an RS, all steps involving the RS below do not apply."

A specific figure should cover that case.

The figure placed under section 1.4 should be revisited to support the general case where the RO may interact either with only the RS or with both the AS and the RS.

It should also indicate the optional steps/exchanges that can be performed, in particular a discovery mechanism for both the RS and the AS.

The uses cases that follow are all or mostly covering the case where the resource owner (RO) and the end-user are the same person).

The general case should be first addressed and the specific cases should be addressed afterwards (in particular, the cases where the RO and the end-user are the same person).

[jricher]

I agree we should add a figure that shows the non-RS use case (identity-only), but in a new subsection. The general diagram is meant to show all of the potential moving parts, not one specific method. This is difficult to convey, but the surrounding text tries to say that.

Note that in the GNAP model, the RO never interacts with the RS. The RS is an API and is not user-interactive.

[agropper]

There are many privacy considerations to consider and too many suggestions floating around the Issues for me to keep track of. @jricher contribution to the wiki is a great start and we might add privacy considerations there.

The issues seem to be in three related categories: Discovery, Identity Providers, and Notification.

IMHO, GNAP should avoid anything to do with discovery as much as possible. There are privacy interests on both the RO and the RQ and we can't make any assumptions about whether the AS is self-sovereign to the RO, fiduciary to the RO, or more like a data broker for multiple ROs. Whether a RQ goes to the RS or AS first is a matter discovery. Can we keep that out of GNAP?

The RO, RQ, and RC may all need a trusted identity at various phases of GNAP. Privacy considerations should allow either the RQ or the RC to be the root of trust so that the RQ can choose to be shielded by the RC. The RO should be able to hold the RQ accountable for the RC they choose just like we hold the RQ accountable for the user agent they use. Non-repudiable signatures must be supported. The RS should be able to demand trusted identity for the RC or even the RQ. The AS needs to be just an agent of the RO in all of these cases and the RS should accept this agency in all cases where they are willing to serve the RO as their client / customer. GNAP should also allow for notaries and auditors that can verify identity and enable an audit trail without themselves ever having access to the content of the authorized transaction.

Notification of the RO is also needed at various phases of GNAP and has privacy considerations. The RS may need to notify the RO in case of exceptions, (e.g. when the AS as the delegate of the RO is not sufficient) and allow the RO to respond with an override or confirmation (as might be required by law). The AS should be able to mediate for the RO to avoid correlation across RSs for authorization as well as notification. Notification between the RQ and RO may be needed in cases. Notification also plays a role in establishing trusted identity.

The wiki should also try to address the relationship of GNAP to Zero Trust Architecture.

This is not an exhaustive list of privacy considerations. GNAP needs to try and keep as much of this out of scope as makes sense while considering #175 and https://mailarchive.ietf.org/arch/msg/txauth/kn-zLiwBvbQe45vL_ctWkwK8ZIs/

I hope we can find a clearer way to illustrate these relationships than what I have above.

[fimbault]

+1 for a wiki section on privacy to clarify the main assumptions.

[Denisthemalice]

To Justin:

I agree that the non-RS case should be illustrated separately in a new sub-section.

However, you wrote:

 "Note that in the GNAP model, the RO never interacts with the RS. The RS is an API and is not user-interactive".

The current definition of a RO is:

"Resource Owner (RO) subject entity that may grant or deny operations on resources it has authority upon.

Note: the act of granting or denying an operation may be manual (i.e. through an interaction with a physical person) or automatic (i.e. through predefined organizational rules)".

This means that in the GNAP model, a RO may be an autonomic process using rules defined by the RO. That case is rather important since it allows to support the verification of attributes placed inside an access token instead of rights (i.e. capabilities) placed inside an access token.

The use of attributes presents significant privacy advantages when compared to the use of rights, especially in the context of the Internet. In the context of an Intranet used by a single enterprise, the use of rights allows to centralize the management of the accesses at the level of a single AS with the ability for that AS to be aware of all the operations likely to be performed at the RSs and, if Token Introspection is being used, to be also aware of the exact instant of time where every operation is indeed performed at every RS.

The general diagram does not show "all of the potential moving parts":
Discovery at the RS or at the AS are optional and should also be described and illustrated.

It does not show either that an optional authentication exchange may need to take place before an operation can be presented at the RS and granted by the RS.

Multiple splits are needed in order to address these cases.

[fimbault]

That's not in the current spec (more focused on actions, such as read/write), but I guess it would be possible to request some specific attributes (ex: role) by extending the access_token/access json.

Something like

"access_token": {
    "access": [
        {
            "roles": [
                "admin"
            ],
            "locations": [
                "https://server.example.net/",
            ]
        }
]}

(as an alternative to type/actions/datatypes)? Is my understanding correct?

[Denisthemalice]

Justin wrote:

"Note that in the GNAP model, the RO never interacts with the RS".

I disagree. The model should be able support either or both capabilities (i.e. rights) and attributes. In both cases, a RO needs to interact with a RS:

• when capabilities are being used, the RO needs to tell to the RS from which ASs which methods can be accepted and on which objects.
• when attributes are being used, the RO manages the ACLs (Access Control Lists) of the RS and needs to tell from which ASs which attributes types and values may be accepted.

In the case of the use of capabilities, relationships must exist between ASs and ROs.

In the case of the use of attributes, the RO of the RS decides which ASs it can trust and for what. The AS does not need to establish any trust relationship with RSs.

[jricher]

In neither case does the RO interact with the RS, as the RS has outsourced that functionality to the AS. What you are describing are functions of the AS, and it is not helpful to the conversation when you ascribe those functions to a different component (the RS).

[fimbault]

Well here I'm not sure. I don't think we are here to prescribe what the RS should/must do (or not), it's really like boiling the ocean (that's the same problem with RS discovery for instance). So the same argument makes it's possible that the RO might interact with the RS. I mean, if the RO has an account at the RS and defined some rules there, it might very well benefit from that. We don't care in practice what happens there, but a practical implication on the boundary for GNAP we need to make is what I described above. For instance, do we allow roles/groups? (you do see some JWT tokens today doing that).

[jricher]

The important part is what happens within the GNAP protocol. If the RO interacts with the RS, that's outside our view and the protocol does not define that action. Considering that we define the RS as an API, and people do not interact with APIs (software does), I think this is an appropriate boundary for GNAP to follow. The consent interactions that Denis describes happen at the AS, within GNAP -- or at the least, they happen at a component which then reports a result back to the AS so that it can issue tokens. This is separate from the question of how the AS is deployed, which is at the heart of the trust model that is at the heart of these issues. In my view, what's being called the "RS" here is really the "RS+AS" and what's being called the "AS" is really an agent that's more part of the client, and what's being called the client is again more part of the "AS" structure. It seems to me that what's confusing here is the application of established terms with specific roles and definitions to other parts of the system that have different names and roles.

[fimbault]

Yes, I agree we need to keep our focus on the AS.

[agropper]

I agree with Justin and with keeping our focus on the AS.

I can see how GNAP can keep AS registration with the RS out of band. When a client presents with a filtered capability originated by an RS, the AS is irrelevant. In this model, the RO gets a capability from the RS and transfers that capability to some AS that is then responsible for processing requests into filtered capabilities.

In this model, the RO user agent (maybe a mobile app) is interacting with the RS and then with an AS. The RS never knows who the AS is. When the RS is presented with a capability and there's an exception, who does the RS notify? In this model, the RS has registered a communication service endpoint of the RO rather than an authorization service endpoint of the RO. It's possible, I guess, for the RO communication service endpoint to be part of the capability so that the RS does not have to register any identifiers for the RO at all.

A privacy perspective might help us explain GNAP AS focus to SSI folks and others. Every end-user has a privacy interest. The RO wants to share as little information with the RS as possible and the RQ wants to share as little information with the AS and the RS as possible. In the real world, we need the RS to be able to handle exceptions, such as a request for a client software statement under HIPAA. Separately, an end-user of a delegated capability might not want to share any attributes with the RO or AS because they are just a delegate of the RQ that made the request to the AS.

To account for different privacy interests, GNAP could define an AS as the RO-delegate that processes requests into capabilities. The RO delegation process to an AS would include some combination of handing them a capability (typically as originated by an RS) as well as a set of request processing policies. The case when an RS puts an AS into their ACL instead of issuing a capability would also be specified. An RO could then be given the choice of approaching an RS with a communication endpoint or an authorization endpoint (or both). Either way, GNAP separates the policy enforcement point from the policy decision point.

We also may need to consider audit of the client-RS transaction by third parties. Who chooses the auditor? How do we minimize privacy risks to the RO? If the RS has no connection to the AS, how does the RO or their delegate ever get a log of resource access?

Adrian

On Tue, Mar 2, 2021 at 1:02 PM Fabien notifications@github.com wrote:

Yes, I agree we need to keep our focus on the AS.

— 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/192#issuecomment-789099818, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YKSMTCOU7LS6NIYITDTBURZNANCNFSM4XYV2QMQ .

[Denisthemalice]

Hi Justin,

You wrote:

The consent interactions that Denis describes happen at the AS, within GNAP -- or at the least, they happen at a component which then reports a result back to the AS so that it can issue tokens.

You misinterpreted what I was saying. As soon as a RS is trusting more than one AS (so it can accept some access tokens with some specific content), the end-user consent CANNOT happen anymore at the AS since it must be obtained from the end-user before he is calling one or more ASs.

The user consent cannot be reported to the AS since it needs to happen before the access token requests are done to these ASs.

The consent is NOT provided through a dialogue via the API. I proposed to use a different end-point at the RS to handle the UI with the end-user. A programmatic language fairly different from the one used on the API end point can be used for it. An alternative way would be for the RS to transmit to the client through the API the data relevant for the user-consent so that it can be processed locally using a UI on the client side.

You also wrote:

This is separate from the question of how the AS is deployed, which is at the heart of the trust model that is at the heart of these issues.

You mention "the trust model". I searched in the current draft the word "trust" and the only occurrences I could find were in such sentences:

Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents

The fact is that the trust model is currently left undefined.

Until we define a trust model, we will not be able to converge.

Note: It is important to remember that a trust condition is not expressed as " A is trusting B ", but as "A is trusting B for doing some action(s) C".

At the very beginning of section 1.4 (or before it) the trust model should be defined. Then, the general case where a RS is trusting more than one AS should be addressed. The interactions with the end-user, in order to obtain the user consent and upon his request to explain the rational for proposed choices (user notice) should also be explained.

My current conclusion remains the same : The first figure in section 1.4 should be split and revisited (which is the title of this thread).

[jricher]

You misinterpreted what I was saying. As soon as a RS is trusting more than one AS (so it can accept some access tokens with some specific content), the end-user consent CANNOT happen anymore at the AS since it must be obtained from the end-user before he is calling one or more ASs.

Within one transactional request to an RS there is a single AS. The fact that the RS might also accept things from other AS's is a matter of the RS's policies.

The user consent cannot be reported to the AS since it needs to happen before the access token requests are done to these ASs.

This is simply untrue. The consent is gathered during the negotiation process. It's not a single call. You are presuming a very specific model that does not map to the experience that's going in here, and so far I'm not seeing support from the WG for your proposed alternative model. In addition, I still believe that it's perfectly reasonable to cast the actions you describe as other roles, but you need to apply the labels differently.

The consent is NOT provided through a dialogue via the API. I proposed to use a different end-point at the RS to handle the UI with the end-user. A programmatic language fairly different from the one used on the API end point can be used for it. An alternative way would be for the RS to transmit to the client through the API the data relevant for the user-consent so that it can be processed locally using a UI on the client side.

Once again you are describing functionality that is defined as part of the AS, not the RS. You are describing a very, very different kind of protocol, but I still believe it's not necessary to do this (or even to define different endpoints for functionality) because you can accomplish what you're talking about already, but what you call the "RS" is actually a combination of the "AS" and "RS" that's controlled by the RS's operational party. The claims and identity inputs to the AS are coming from external parties.

[fimbault]

My advice would be to really speak in the current language of GNAP

• RQ is now end-user
• client, RS and AS are quite precisely defined

There's no problem in making changes if that makes sense (meaning WG consensus) but we need a common starting point, and that's the draft-04.

[aaronpk]

The editors are marking this issue "pending close" since the many issues brought up in this thread have been resolved:

• new diagrams have been added for the case when there is no RS (section 1.4.6)
• we've clarified that the RO does not interact with the RS
• the AS-RS parts have been moved to a new draft

[Denisthemalice]

The first figure in section 1.4 has indeed been revisited with a major change: the first interaction between the client and the RS has been removed !

The (single) good news is that a new diagram has been added for the case when there is no RS case. Thanks.

However the remaining of the section still only contains examples where none of them is addressing the case of an end-user, a Client, an AS and a RS and no human RO.

The text says;:

" The client instance determines what access is needed and which AS to approach for access".

How can it do that ? Shall the client manage a list of RSs associated with a list of ASs ? or does it mean that one RS only trusts one AS ?

The text continues with:

"Note that for most situations, the client instance is pre-configured with which AS to talk to and which kinds of access it needs.

The text is silent on how to handle these other situations.

@aaronpk: You wrote:

we've clarified that the RO does not interact with the RS".

Well, where is this done ?

The current definition of a RO is still the same and does not contain such a restriction:

Resource Owner (RO)

subject entity that may grant or deny operations on resources it has authority upon.

Note: the act of granting or denying an operation may be manual (i.e. through an interaction with a physical person) or automatic (i.e. through predefined organizational rules).

This definition clearly allows to use both ACLs and Capabilities.

Since the document still does not contain any section about the trust relationships between the different roles, it is impossible in particular to know how ROs at the AS are being established.

In the case where capabilities only are being used:

Q: Can an RS trust more than one AS ? A: I would believe so.

Q: Can an AS trust more than one RO ? A: I would believe so.

Q: What does it trust if for ? A: An AS trusts a RO to deliver access tokens for a set of URLs and to enable a (restricted) set of actions.

Q: Which rules should be established on the RS side to check the access token delivered by an AS ? A: The RS Manager (which I called RO in my previous posts) indicates that access tokens coming from a given AS may only apply to a set of resources (URLs) and only contain a restricted set of actions, otherwise the access token will be discarded.

At the moment, the text is silent about the processing of the access token on the RS side. The text states:

The means of the RS determining this access are out of scope of this specification, but some options are discussed in [I-D.draft-ietf-gnap-resource-servers].,

Except for the case of a call back from the RS to the AS (i.e. Token Introspection), the text remains silent. The case where the RS is able to understand itself the content of the access token should be addressed in the core document.

Q: Should the GNAP model able to handle ACLs ? A: I would believe so.

If this would NOT be the case, this should be clearly advertised before section 1.4.

If it is the case, let us address the case where capabilities are not being used, but where ACLs are being used.

An ACL may contain associated with a set of actions on a resource : subject identifiers, roles, hierarchical group memberships, functional group memberships, clearances, subject attributes, etc ...

Subject identifiers, roles, hierarchical group memberships, functional group memberships, clearances, subject attributes, etc ... can be managed by one or more AS. The AS will deliver such information if the client requests for it and if the end-user consents to the inclusion of such information within an access token.

Such scenario is currently NOT addressed but should be addressed.