Requesting RO Information or Requesting Subject Information?

[Denisthemalice]

Section 2.2 is currently called:

Requesting Subject Information

Then the text continues with:

If the client instance is requesting information about the RO from the AS,

This means that this section is currently restricted to the RO. Since this call is restricted to the RO, the title of this section should be changed into: Requesting RO Information.

In addition, the reason(s) for requesting such information is not mentioned and should be explained.

As a side-consequence, a user has no on-line means to know which personal data the AS knows.

This comment also impacts the content of section 1.4.6 (Requesting User Information). This topic has been first addressed under the issue #197 which is still open.

It would be wise to allow such an on-line access so that the user can know which attributes are known by an AS and then choose which attributes to insert into an access token.

[fimbault]

Maybe we'll need a bit of rewording, although I'm not sure the proposed changes help so much. I just think we should put more emphasis (and state early on) what is shortly described at the end of section 4, i.e. that here RO = end-user

[Denisthemalice]

RO = end-user is not the general case.

The usefulness of supporting Requesting RO Information is not crystal clear and should be indicated, but there is an interest to support Requesting User Information.

While I agree with you that "we'll need a bit of rewording", simply stating that RO = end-user in section 4 will not solve the issue.

[elf-pavlik]

I notice that 1.4.6. Requesting User Information states

... If the request has been authorized, the AS grants access to the requested direct subject information (Section 3.4) to the client instance. At this stage, the user is generally considered "logged in" to the client instance based on the identifiers and assertions provided by the AS.

It also shows that there is no RS involve and diagram uses label: User (not RO)

To my understanding End-user is "logged in" to the client instance. Given role definition:

End-user

natural person that operates a client instance.

If we don't have RS involved, so we also don't have any Protected Resource here, does it really make sense to speak of Resource Owner?

[fimbault]

Yes, that's why we talk about the "user" here. Notice that currently, this term is used when we don't know the exact role it will play in the protocol (end user or RO).

[elf-pavlik]

If that's the case for 1.4.6. Requesting User Information why does 2.2. Requesting Subject Information speak about Resource Owner? Again in 2.2 we also don't seem to have Resource Server or Protected Resource involved.

[fimbault]

The rationale is :

• in the intro of section 4, gnap allows a large variety of cases. GNAP can handle UMA2 types of scenarii (hence 1.4.6 and a few other places)
• but in gnap core we mostly detail the case where end-user = RO. Hence what we explain about the subject, and it makes sense to limite the diffusion of confidential information about the RO (the most limiting case, hence 2.2 and a few other places)

That's actually a quite subtle difference, but i think it makes good sense.

[elf-pavlik]

Resource Owner (RO)

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

Protected Resource

protected API (Application Programming Interface) served by an RS and that can be accessed by a client, if and only if a valid access token is provided.

Given above definitions maybe it would make sense to broaden definition of RO to:

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

Since in 2.2. Requesting Subject Information the User acting as RO doesn't grant or deny operations on resources (served by RS) but only grants / denies obtaining an assertion.

[jricher]

I agree that the specific language that @elf-pavlik references should be tightened up. What's a little awkward right now is that GNAP's language treats access to an RS and access to information contained in assertions as protected resources, but it doesn't do so particularly cleanly due to several major text revisions that have changed things a little out of sync with each other.

Both data from an RS (using an access token) and assertions/identifiers passed to the client are targeted at the client itself, so in that way they're the same nature, a protected resource after a fashion and both controlled by an RO of some kind. What's different is that the info passed back directly is usually assumed to be :about: the end-user, because that's what the client is calling about in just about all the use cases that are known.

Technically all of the information, either from an RS or subject information passed directly, is controlled by the RO. The end-user can get involved through interaction and act as the RO. The case where the RO doesn't equal the end-user is useful in many situations but leads to unexpected weirdness when you're talking about the subject information coming back.

[fimbault]

Fair point. We might start by listing what needs to be changed.

[agropper]

I tend to think of the AS as having a separate service endpoint for RO requests because they are the ones that can edit AS policy. A service endpoint that is accessible to End User requests would be "separate" and could be used by anyone including the RO when they want the protection of least-privilege. This distinction may be unhelpful in the general case of explaining GNAP so I don't mean to overstate it.

[jricher]

@agropper when you say "service endpoint" are you thinking of something that's interactive and user-facing (so a webpage) or something that's a callable API?

[agropper]

@jricher, I really don't know enough to answer purely technical questions. I think mostly in terms of privacy engineering and look to this group for security and devops perspective.

Therefore, I focus on the AS as the primary, if not the sole, entity that stores and executes RO policy. The AS takes requests and turns them into access tokens. The requests might be via (RAR) API or a web form. Either way, this request interface is likely unsecured. Some requests present credentials while others might add an authentication flow.

That begs the issue of how did the AS get the RO's policies to begin with, long before a request comes in? I would define whoever sets the AS policies as the RO (regardless of any particular RS-RO relationship). A so-called "policy manager API" has been under discussion in UMA for about a year because at least one implementer wants to author policies on a mobile app and standardize the way they are uploaded to the AS.

Back to Justin's technical question, I'm trying to implement the shortest distance between OAuth 2 and GNAP in a way that I can understand and explain to others.

• I'm doing this in FastAPI (because I don't know much beyond elementary Python, because it has built-in OpenAPI documentation, and has some OAuth 2 and JWT functionality).
• I'm deploying (automagically) to DigitalOcean App Platform in order to be clear about my various security and build shortcuts.
• I've designed the demo as two separate FastAPI server domains for the RS and AS. A "global" CouchDB instance is deployed for RO policy storage and any state that needs to be saved as part of the protocol demos. -- https://github.com/agropper/OGNAP (the AS) and running at https://ognap-xf7vq.ondigitalocean.app/ -- https://github.com/agropper/OGNAP-RS and running at https://ognap-rs-me9ms.ondigitalocean.app/ -- http://couchdb00.hagopian.net:5984/_utils/#database/hieofone2/_all_docs
• The protected resource is going to be just a self-verifying vaccine credential (I invented) -- https://github.com/HIEofOne/Trustee-Community/wiki -- Some of this is running at https://adriang.xyz/

I've been stuck trying to answer Justin's exact question for quite a while. I think I need to set up the AS (OGNAP) to deliver a PWA to the RO so they can edit policies locally in PouchDB and sync the polices with the CouchDB the AS can access when a request comes in. That forces me to learn Vue.js or something like it.

Aside from my long-term goal to upgrade the HIE of One Trustee demo from UMA to GNAP, I'm also hoping to show the W3C and DIF protocol groups how easy it could be to mitigate significant OAuth 2 human rights concerns using GNAP.

Any suggestions, help, moral support would be really welcome.

[fimbault]

back to @elf-pavlik and @jricher : looking again on this. I guess we could define what we mean by operations. Getting an assertion is an operation, in my view. Or give it as an example. What do you think ?

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

Protected Resource protected API (Application Programming Interface) served by an RS and that can be accessed by a client, if and only if a valid access token is provided.

Given above definitions maybe it would make sense to broaden definition of RO to:

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

Since in 2.2. Requesting Subject Information the User acting as RO doesn't grant or deny operations on resources (served by RS) but only grants / denies obtaining an assertion.

[jricher]

I think it comes down to whether or not we consider the "subject information", which includes both identifiers and assertions, to be "resources" or not. I always thought they are, but they are definitely a different style of resource than what comes from the RS so maybe we need better wording around it. We talked about it a bit in the long terminology discussion a year ago, but I don't think we ever really landed on a term that fully captures "stuff sent directly to the client by the AS and not accessed through the RS". Identifiers and assertions are the two categories where there's clear demand, but other things could happen through extensions as well.

[agropper]

Does this issue also have to align with authentication flows that build on GNAP?

• a subject presents a DID or other identifier to a relying party (RP)
• the RP dereferences the identifier to an AS they trust
• a request for assertion is made to the AS
• the AS issues a liveness challenge to the subject
• the AS returns an assertion and attributes to the RP (the attributes might be accessed indirectly via an access token returned with the assertion)

How is SIOP planning to handle this?

[fimbault]

• In the current draft, section 2.2 : "The AS can determine the RO's identity and permission for releasing this information through interaction with the RO (Section 4), AS policies, or assertions presented by the client instance (Section 2.4). If this is determined positively, the AS MAY return the RO's information in its response (Section 3.4) as requested."
• Currently, a resource is just a short cut for "Protected resource", which really refers to an API served by a RS. So we have a mismatch (or at least a missing case) in the RO definition (as pointed out by @elf-pavlik and @jricher). I've tried some sentences to specify subtypes for resources, but it becomes very confusing.

The proposal by @elf-pavlik to define the RO as "subject entity that may grant or deny operations on resources or obtaining assertions it has authority upon." seems slightly incorrect to me, because the assertion is not made by the RO, but by the AS. What the RO grants to the AS is access to its attributes (and then the AS may carry out further due diligence to derive assertions, for instance through AuthN flows as suggested by @agropper).

The decision to disclose or not its own attributes is not restricted to the RO, it's actually something under the control of every subject.

So here's what I'd suggest to solve the issue (new part in bold): update the definition of "Subject: person, organization or device. It decides whether and under which conditions its attributes can be disclosed to other parties."

• question 1 : should we limit this to physical persons? (from a legal perspective, that makes sense, but then wouldn't an org want to restrict what it shares, cf issues around data sovereignty?). I think the principle could be generic.
• question 2 : I've added under which conditions because we already discuss that in the text (manual consent, automatic policy, etc.), plus it's not only a yes/no, it also concerns what those other parties can do with it, including further sharing those attributes, cf the case mentioned by @agropper where the AS sends them to the RP. Feedback welcome !

[elf-pavlik]

The decision to disclose or not its own attributes is not restricted to the RO, it's actually something under the control of every subject.

Requesting Subject Information section refers to the Subject exclusively as RO.

I'm still uncertain if the subject who in interaction only decides to disclose some attributes in an id_token but not any "Protected resources" (an API served by RS) is considered to act as RO. If that's the case what would be the case where the subject decides to disclose some attributes but doesn't act as RO?

[fimbault]

I'm not entirely sure about the use case you're targeting here. Could you be more specific ?

[elf-pavlik]

Maybe I shouldn't have mixed two questions together. Let's focus on one of them first.

Requesting Subject Information section always refers to the Subject as RO.

In your previous comment you mentioned that:

The decision to disclose or not its own attributes is not restricted to the RO, it's actually something under the control of every subject.

When we would have a situation where a Subject is deciding to disclose its own attributes but they don't act as RO?

[fimbault]

In theory section 4 allows other situations (at the beginning of the section). But the only case that's detailed is the case where it is indeed the RO.

[elf-pavlik]

Thanks, now for the second part of my question.

In Requesting User Information we find:

In this scenario, the client instance does not call an RS and does not request an access token. Instead, the client instance only requests and is returned direct subject information.

In this scenario, while no RS is participating, so no Protected Resources are being accessed. We still have

The user authenticates at the AS, taking on the role of the RO.

Shouldn't definition of RO should still be broadened from current

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

Keeping in mind

The proposal by @elf-pavlik to define the RO as "subject entity that may grant or deny operations on resources or obtaining assertions it has authority upon." seems slightly incorrect to me, because the assertion is not made by the RO, but by the AS. What the RO grants to the AS is access to its attributes (and then the AS may carry out further due diligence to derive assertions, for instance through AuthN flows as suggested by @agropper).

It might still be something in direction of

subject entity that may grant or deny operations on resources or obtaining assertions containing attributes it has authority upon.

In short, if RO plays role in Requesting User Information. There seems to be more to that role than just granting or denying operations on resources (an API served by RS).

[fimbault]

My view is that the attribute part is covered by the fact that the RO is a subject (obtaining them is covered by the subject definition now). The main rationale for the protocol is still related to access to protected resources, and I believe we would dilute that otherwise.

[elf-pavlik]

In that case is there any reason for Requesting User Information to still include:

4. The user authenticates at the AS, taking on the role of the RO.
5. As the RO, the user authorizes the pending request from the client instance.

I think 4 could be removed altogether and 5 could become (after renumbering)

4. As the subject, the user authorizes the pending request from the client instance.

This section states in the first sentence that it does not involve RS and access to protected resources (an API served by RS)

In this scenario, the client instance does not call an RS and does not request an access token. Instead, the client instance only requests and is returned direct subject information.

[fimbault]

We still need to make sure that the user is indeed the RO, hence step 4.

[jricher]

I still consider that the information about the subject is counted among the "Resources" being released here. The only real difference is that instead of them being at an RS, they're passed directly to the client instance.

[fimbault]

Yes, this didn't change. I'm only saying I don't think it needs to be embedded into the RO definition, since we can assume from the subject definition itself that some mechanism exists to grab the subject attributes data if it consents to.

Changing the RO definition or worse the (protected) resource definition makes the entire thing convoluted, at least in every variation I tried.

[jricher]

@fimbault Right, and I think I agree with that. The definitions should try to stay tight, if we can. But if the surrounding text, especially the "subject information" request stuff isn't clear, then this is going to come around again. I don't have a specific answer but I would be surprised if we can't improve this, since it's come up a few times.

[Denisthemalice]

I am supportive of elf-pavlik when he writes:

Requesting Subject Information section refers to the Subject exclusively as RO.

fimbault agrees with him when he says:

In theory section 4 allows other situations (at the beginning of the section). But the only case that's detailed is the case where it is indeed the RO.

When looking at Section 3.4 that is indicated in that section, the following text may be found.

If information about the RO is requested and the AS grants the client instance access to that data, the AS returns the approved information in the "subject" response field.

The case where information is about the end-user is not addressed, i.e. there is no sentence starting with:

If information about the end-user is requested (...)

Does this mean that an end-user is not allowed to know which personal data is known by the AS about him ? If this would be the case, such a limitation would not comply with generally agreed privacy principles.

The text is still not fixed in draft-08.

What are the benefits for a client to know information about the RO ?

This may be crystal clear for the editor(s), but it is unclear for a lambda reader.

[elf-pavlik]

Based on recent conversations, especially https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/291#issuecomment-953151121 it seems to me that the intention is to consider the subject as RO with regards to the information about them. I think this shows up clearly in Requesting User Information since it does not involve any Protected Resources but it stills call the user RO.

It might be helpful to document scenarios where there is more than one AS involved. Let's say we have Alice using a client to access resources owned by Bob. Here we could have two different AS:

• AS providing user information about Alice to the client - here Alice would act as both End-user and RO and Bob not be involved at all
• AS providing access_token to the client allowing access for protected resources - here Alice would act as End-user and Bob as RO

Does that scenario with two different Authorization Servers sound reasonable?

[jricher]

@elf-pavlik Those two both make sense, and it makes sense even for them to be together. You could have those be the same AS as well, if Bob's resource server is protected by the same server Alice is using to log in to the client. But they're different kinds of access, and it would make sense to talk about them in a single example scenario to help call out that difference.

There's also a weird case from the CIBA work in the OIDF: Alice uses client software to find out who Bob is. The canonical example given here is a call center: Alice needs to verify that the person calling her is actually Bob, and so Alice starts something with the AS that reaches out to Bob to approve the release of identity information about Bob to Alice, in real time.

[elf-pavlik]

Alice needs to verify that the person calling her is actually Bob, and so Alice starts something with the AS that reaches out to Bob to approve the release of identity information about Bob to Alice, in real time.

@jricher how does Alice know which AS can release identity information about Bob? I would not make an assumption that one global central AS exists and it has information about the whole Earth's population?

[jricher]

@elf-pavlik This use case is not assuming a global AS at all (I agree, that's absurd), but it is assuming that Alice and Bob are both working with a known ecosystem. In the case of the call center example, it's the supporting company's AS -- where Alice works and where Bob is a customer. So, Bob needs to have an account there, and so does Alice. Alice's account needs to be authorized to get info about other users (because she's a support tech). Bob's account is a customer account that Alice can fetch information from anyway.

[elf-pavlik]

I see, thank you. It indeed looks like another use case where Bob acts as RO but there is no RS or Protected Resource involved.

[fimbault]

I've encountered the CIBA use case very recently.

Here's a summarised description :

• the enduser gets in touch (out of band) with the support, so that both are available at the same time
• the support needs to get read access to some info stored on the enduser's mobile, and uses CIBA to get the enduser's approval
• returned scopes define what can be accessed through another OIDC client (used by the support agent)
• there are no RS involved

Note : this issue is closed, so either we should reopen it or open a new issue

[jricher]

@fimbault Agreed, we've drifted off of the topic of the issue as well. I opened up a new issue for discussion of the cross-user CIBA use case specifically: #350