Draft: draft-ietf-gnap-core-protocol

Commentary: Opaque identifiers provide a generic reference , so we can simplify the text . ( mainly ) , and as a byproduct also and - removed userhandle from main response in section 3 changed title of section 3.4 ( User -Subject ) and moved the text that requires RO = end - user at the top of the section , for clarity changed name ( userhandle -user ) and wording in section 3.5 . Maybe we could also simplify the title " Returning Dynamically - bound Reference Handles " into " Returning Reference Handles " ( did n't do it yet ) . 
 Deploy Preview for gnap - core - protocol - editors - draft ready ! Explore the source changes : Inspect the deploy log : Browse the preview : 
 With the adoption of the subject identifier format , we no longer need to have a GNAP - specific value and can instead leverage this more standard field . Alternatively , we could have a GNAP - specific subject identifier format , instead of a separate field . 
 In section 2.4 ( Requesting User Information ) , the first sentence starts with : If the client instance is requesting information about the RO from the AS , ... From the title , the acronym " RO " should be changed into " end - user " . The case where the RO is also the end - user is a specific case . This leads to the following change : If the client instance is requesting information about the end - user from the AS , ... In the following sentences of this section , RO should be changed into end - user . 
 The current text really means RO , and generally considers the case end - user = RO . Any other case would even trigger an error : " If the identified end - user does not match the RO present at the AS during an interaction step , the AS SHOULD reject the request with an error . " ( section 2.4 ) Which makes sense because why would we return something about the RO to a potentially unknown end - user ? ( the only problem is that this wording is buried in the text , so it 's hard to understand ) Back to the general case : The RO is in control of policies at the AS . The end - user is in control of a client and a request to the AS . The end - user and client may or may not have any prior relationship with the AS . The subject info is what is known by the AS ( in theory could be RO and maybe end - user , but notice that in the terminology , we define the end - user as a natural person and the RO as a subject entity ) . I think we should clarify when we could have a remote RO too . Then do we even return a result if the AS knows something about the end - user ? ( different from RO in that case ) . Plus we need to keep in mind that we also use sub_ids for In general , we might want to avoid the term " user " as it is not specific enough . 
 The title has been changed into " Requesting Subject information " . This title is incorrect as long as a subject can be also an organization or a device . An AS can hold information about an end - user or about RO when the RO is a human being . It does not hold information about organizations or devices . However , an end - user may belong to some organizations or / and use some devices . IMO , I would replace it by " Requesting end - user Information " . If an AS holds information about an end - user , it seems logical that the end - user should have access to it . If it happens that the end - user has also a RO account on the AS , then it should also have access to it . In such a case , another section with the following title " Requesting RO Information " should be created . RO = end - user was a common case in OAuth . In GNAP and in the general case a RO is different from an end - user and an AS may have no relationship with any RO ( e.g. when attributes only are being used ) . 
 I guess you refer to " 2.2 . Requesting Subject Information " . We might have to harmonize a bit , but for instance " 2.3 . Identifying the Client Instance " might very well hold information about devices or at least the software running on it ( that 's the point of client software attestation to be discussed in ) We do n't always know in advance whether it will be a RO or an end - user only , so the proposal is n't always applicable . 
 I was indeed referring to " 2.2 . Requesting Subject Information " which has no relationship with " 2.3 . Identifying the Client Instance " . This means that your arguments do not apply to section 2.2 . and , by implication , that my argumentation currently remains valid . 
 Well , I take the point in consideration but I do n't think we should base our reasoning on the structure of sections , which can change 
 Identifying the User by Reference : Editor 's note : We might be able to fold this function into an unstructured user assertion reference issued by the AS to the RC . We could put it in as an assertion type of " gnap_reference " or something like that . Downside : it 's more verbose and potentially confusing to the client developer to have an assertion - like thing that 's internal to the AS and not an assertion . 
 Why an assertion ? Is that reference supposed to be linked to a session ( cf " represent the same end - user to the AS over subsequent requests " ) or can it be persistent ? I would see that more as an opaque identifier , rather than an assertion . Something like : asref seems a bit specific to GNAP ( reference managed by the AS ) but it could always be read " as a reference " in a more general setting . There 's a variety of generic names that we could choose if needed , localuid , internal_uid , etc . But that really asks what additional types we could define as part of secevents ( section 7.1.2 ) . Beyond the case mentioned here , it would be most useful as an opaque identifier when RO ! = end - user , to avoid leaking private info about the RO ( although currently we do n't seem to cover that case yet ) It 's indeed more verbose than " user " : " XUT2MFM1XBIKJKSDU8QM " but at least it 's always the same structure ( does n't depend whether it 's a reference or not ) , and it also makes the type more explicit . 
 A subject identifier makes sense here , and I agree that it should be a new value to let us constrain it to the GNAP context . 
 Fixed by SECEVENT opaque identifiers 
 I do n't think this goes far enough -- I am thinking that with the opaque identifiers we can now simply return a with a format of that the client can be allowed to send in a follow - up request if it wants to . This way they all get treated equally , there 's no special field anymore .
Paragraph (version A):
Claims about the RO as known and declared by the AS.
Paragraph (version A):
An identifier this client instance can use to identify its current
end-user when making future requests.
Paragraph (version B):
Claims about the RO as known and declared by the AS, as described
in response-subject.
Paragraph (version A):
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.  This field is an object with the
following OPTIONAL properties.
Paragraph (version B):
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 AS MUST return the "subject"
field only in cases where the AS is sure that the RO and the end-user
are the same party.  This can be accomplished through some forms of
authorization.
Paragraph (version B):
This field is an object with the following OPTIONAL properties.
Paragraph (version A):
The AS MUST return the "subject" field only in cases where the AS is
sure that the RO and the end-user are the same party.  This can be
accomplished through some forms of authorization.
Paragraph (version A):
All dynamically generated handles are returned as fields in the root
JSON object of the response.  This specification defines the
following dynamic handle returns, additional handles can be defined
in IANA.
Paragraph (version A):
A string value used to represent the current user.  The client
instance can use in a future request, as described in request-
user-reference.
Paragraph (version A):
This non-normative example shows two handles along side an issued
access token.
Paragraph (version B):
All dynamically generated handles are returned as fields in the root
JSON object of the response.  This specification defines the
following dynamic handle return, additional handles can be defined in
IANA.
Paragraph (version B):
This non-normative example shows one handle along side an issued
access token.