Change:
client instance (such as the subject of an issuer and subject pair), while others forms (such as email address and phone number) are intended to allow the client instance to correlate the identifier <del> with other account information at the client instance.  The client instance MUST NOT request or use any returned subject identifiers for communication purposes (see request-subject).  That is, a subject identifier returned in the format of an email address or a phone number only identifies the RO to the AS and does not indicate that the AS has validated that the represented email address or phone number in the identifier is suitable for communication with the current user.  To get such information, the client instance MUST use an identity protocol to request and receive additional identity claims.  The details of an identity protocol and associated schema are outside the scope of this specification. </del> <ins> with other account information at the client instance.  The AS MUST ensure that the returned subject identifiers only apply to the authenticated end user.  The client instance MUST NOT request or use any returned subject identifiers for communication purposes (see request-subject).  That is, a subject identifier returned in the format of an email address or a phone number only identifies the RO to the AS and does not indicate that the AS has validated that the represented email address or phone number in the identifier is suitable for communication with the current user.  To get such information, the client instance MUST use an identity protocol to request and receive additional identity claims.  The details of an identity protocol and associated schema are outside the scope of this specification. </ins> [[ See issue #75 [26] ]]

Discussion:
Reflect the various scopes possible in sub_ids Some are local to the AS, some enable dereferencing
Deploy preview for gnap-core-protocol-editors-draft ready! Built with commit fef94aa06f805be88e9d958929ca0cafe0bd6c8f https://deploy-preview-229--gnap-core-protocol-editors-URL
I'm confused. This reflects that we want to support both locally-scoped subjects and also non-locally ("federated"?) scoped ones. So does the comment in with subject identifiers. But the move to means that we expect the AS to identify a subject using a single string. Why are we getting rid of the issuer URI?
We're not getting rid of isssub, which is also a valid subid. Opaque is just one additional possibility, local to the AS.
I don't think I agree with this change -- even in the case of an AS sending a globally-scoped identifier like iss/sub (or email, or phone, etc), the connection between the user and that identifier is still being asserted locally by the AS. After all, nothing stops a rogue AS from assering an iss/sub pair that it is not the issuer for. And in the case of a user logging in to the AS with a federated identity, that might actually be desirable to know. The intent of the previous language was to say that the AS is only its own authority and not able to make truly global trusted statements. I think that this can be said better but I don't think removing "locally" gets at that and leaves it too open for misinterpretation.
The rationale is that "asserted by the AS" already provides that information, while the scope of the identifier is defined by the choice of sub_id.
I'm always confused by the meaning of subject identifiers in authorization protocols, not just GNAP. I wonder if this URL framing would be useful?
Add some text in the spec saying that the assertion is made locally by the AS
In section 1.3, subject is defined as: Subject person, organization or device. Given the current definition of a Right (ability given to a subject to perform a given operation on a resource under the control of a RS), it does not make sense to consider that a subject may also be an organization or a device.

Delete "organization or a device".
We're mostly interested in having definitions which are consistent throughout the document. In the context of a right associated to an end-user, it is usually applicable to a person. But even then the right could derive from an automatic RBAC system as well. There are other places where subject is applicable to an organization or an IT system, especially for the resource owner. Notice the OR statement, depending on the context it may vary.
A resource owner is still a person: it is neither an organization nor a device: it still does not make sense to consider that a subject may also be an organization or a device.
Not always, the resource owner can very well be your company for instance, and the consent might not require a real person (that's the all point of LDAP for instance).
Do you mean that a subject is either an end-user or a resource owner which may then be either a person or an organization ? Would you have some arguments for a "subject" being a "device" ?
An end user is only a natural person. A RO could be a natural person, an organisation or a device. In the last 2 cases, you have a rule engine instead of a person. An example of a device as a resource owner could be a system (ex a robot, a car, etc.) that controls specific resources. Not very common today tbh, but IoT scenarii make that likely in the future (at least I don't see a reason why it shouldn't be included in a generic definition).
This topic is closely related to the issue . An AS manages end-users and maintains relationships with some ROs, but does not manage organizations, nor devices. "Requesting Subject information" does not really make sense.
We never said the AS managed organisations or devices, and we didn't say either that it managed users. It manages access tokens. It's not because the definition might in some cases allow additional cases that it doesn't make sense. We just need to be very specific as to what kind of subject is concerned when it doesn't apply to all.
Humm ! An AS needs to manage end-users because an end-user needs first to authenticate to the AS before the client it is using may obtain an access token. The authentication mechanism being used is left out of the scope of the document, but an authentication exchange must exist.

Once an end-user has been authenticated, it is possible for the AS to know which are his attributes and upon a request from the client they can be enumerated by the AS. "Requesting end-user information" makes sense. while "Requesting Subject information" still does not make sense.
I've reviewed in detail, and I quite definitely think the current definition is fine and fits well with all sequences in 1.4.x. More info also for IETF110.
Closing as discussed last week on the mailing list
Returning User Information: Editor's note: Subject identifiers here are naturally scoped to the AS; even though using an external identifier like an email address or phone number implies a global namespace in use, the association of that identifier to the current user is still under the view of the AS. Would changing the name to "assubids" or "localsubids" help convey that point? Would it also be desirable to have an identifier that's globally unique by design? The "iss_sub" type almost gets us there by explicitly calling out the issuer URL, but tuples are hard to deal with in practice and so tend to get ignored in practice in the OIDC space.
Having reflected on that, I believe sub_ids should be scoped to the AS (but I don't see the value of changing the label). There's no way GNAP can impose a global identifier even if that existed, and there's even value for GNAP to be able to provide portability between identity systems This is helpful, Denis. I will focus on "Then Bob asks to Alice to issue for him an authorization to access the resource." and avoid using any hammers. Let's use something in the news and say the RS is a hospital that gave Alice a J&J COVID vaccine. Alice identified herself to the hospital with a number N. N could have been randomly chosen by Alice or the hospital or N could be Alice's driver's license number right next to her face photo. GNAP should probably deal with both cases. The hospital creates a digital credential that includes the J&J vaccine name and lot number, N, a statement about how N was derived, and a date. The hospital posts this credential at some resource URL, protected by some access token requirement, and gives Alice the "resource URL" instead of or along with a paper vaccination card with the same information as the resource.

When Bob asks Alice for an access token, Bob makes a request to Alice and she can either: A - Give Bob the "resource URL" and let him try his luck turning this into an access token somewhere, B - Go to the hospital portal and authenticate somehow and grab an access token that she can return to Bob, C - Give Bob an access token for the resource URL based on some signature that is trusted by the hospital. When Bob gets the resource, it will include N along with the hospital's statement about how N was derived. Bob can decide what to do next. Adrian Denis wrote: >