Draft: draft-ietf-gnap-core-protocol

Commentary: 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 https://deploy - preview-229 - -gnap - core - protocol - editors- 
 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 do n'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 do n'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 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 do n't see a reason why it should n'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 did n'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 does n't make sense . We just need to be very specific as to what kind of subject is concerned when it does n'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 :  '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 do n'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
Mailing list commentary: This is helpful , . I will focus on " Then asks to 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 a J&J COVID vaccine . identified herself to the hospital with a number N. N could have been randomly chosen by or the hospital or N could be '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 the " resource URL " instead of or along with a paper vaccination card with the same information as the resource . When asks for an access token , makes a request to 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 , C - Give an access token for the resource URL based on some signature that is trusted by the hospital . When gets the resource , it will include N along with the hospital 's statement about how N was derived . can decide what to do next . Adrian
Paragraph (version A):
statement asserted locally by an AS about a subject.
Paragraph (version B):
statement asserted by an AS about a subject.
Paragraph (version A):
Subject identifiers returned by the AS SHOULD uniquely identify the
RO at the AS.  Some forms of subject identifier are opaque to the
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
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.
Paragraph (version B):
Subject identifiers returned by the AS SHOULD uniquely identify the
RO at the AS.  Some forms of subject identifier are opaque to the
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
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.