Draft: draft-ietf-gnap-core-protocol

Commentary: Suggested changes for 
 Deploy preview for gnap - core - protocol - editors - draft ready ! Built with commit https://deploy - preview-184 - -gnap - core - protocol - editors- 
 Not sure " subjecttypeidentifiers " is best ( when I read that , what my brain remembers is identifiers , and that 's the opposite of what is targeting ) . In 2.2 this is already encapsulated within a " subject " object . In section 9 , that 's not the case ( so we need to explicit that it relates to sub / subject ) -"subidstypes " ? ( which means , a list of types which refer to subject identifiers ) : that 's what I 'd suggest Makes sense also with " Subject Identifier Type " in ( ex : title of section 3.2 ) . In our case the plural seems better to convey the idea of a list . In they use " subjectidtypes " ( kind of the same idea again ) 
 I tried to be consistent with and called it subjecttypeidentifiers , not " subtypids " or something else ... even though , as you know , there is a clear tendency to use short names , e.g. " sub " , " kid " and so on and so forth . IMO , OpenID Connect ( in general ) and OpenID Connect Discovery ( in particular ) , very consistent with naming and uses " subjecttypessupported " and we may also consider using it . What I mean is for section 2 for section 9 
 Yes I like that ( that said , we should decide on a common scheme throughout , if we use the GNAP terminology , that would be request and response , or req / res ) 
 I 've replaced subjecttypeidentifiers by subjecttypessupported which also means is that if you wish to go this route , you would also need to replace at least by keyproofssupported and assertions by assertionssupported _ in section Discovery for the sake of consistency . These changes , as well as the ones in , are n't ideal and , I believe there will be lots of discussions about subject type identifiers . This is just one little step towards clarity . 
 After reviewing with the editors , we suggest that we use " subjecttypes " for section 2 ( to be consistent with secevents ) and " subjecttypes_supported " for section 9 . Then we 'll put it in pending merge status , thanks for your input ! If additional changes for names are suggested for consistency ( keys , assertions ) , a separate PR is probably best for tracking changes 
 I 've these changes and created a separate for Discovery . 
 I just realized that this will also need an updated entry in the Changelog since it 's a substantive change . 
 also fixes a couple of other examples I have n't noticed initially . 
 This PR is fine , but in the future , please do not add additional edits after the editors have marked it " Pending Merge " . If it 's not ready we can back it out of that state , we just want to make sure any WG members have a chance to see the changes as they go in . Thanks ! 
 since SECEVENT has now called the types " format " , just wondering if that should be aligned ( not necessarily as part of this PR , but as one that aligns with draft-07 ) 
 I saw that also , and I think we should do a sweep to align them all in one go . My read of the response to this PR is that there 's support for changing the terms in this direction ( adding _ supported and the like ) . So we might want to hold off on this PR specifically and do all the changes at once . This would affect things I have in and others , so the editors basically just need to rack and stack these to get things fixed throughout the document . 
 ( alternatively we can fold in this PR just to change things again with another PR that aligns the terms , which is also reasonable ) 
 Yes ... it 's quite interesting that the most recent started to use instead of . I believe GNAP should be aligned with Subject Identifiers for Security Event Tokens but it also means it needs to use something a bit more descriptive than something like Discovery parameters ' or more lengthy . Who knows what next versions of draft - ietf - secevent - subject - identifiers would use in the future ? ? 
 I 'm trying to understand how we 're using sub_id . See 
 good remarks . I do n't know why they settled for format , but whatever term they choose , I guess we could ask them to stabilize that once and for all , and avoid forcing us do an additional mapping . For discovery , I would suggest ? 
 Accepting as is , will update all SECEVENT references together in a future PR . 
 It may make sense to use ( or subjecttypeidentifiers ) instead of subids in section 2.2 . Requesting Subject Information ( or subjecttypeidentifiers ) instead of subids in section 9 . Discovery The reason for it is that the same subids has a different meaning in section 3.4 . Returning User Information , where it 's and so on . Furthermore , in section 9 . Discovery could be changed to for clarity . See also 
 I like this idea , as these really are two different entities with different purposes . 
 Makes sense on the general idea ( and aligns with the idea pf -uses " subjecttype " ) Made some comments on the PR regarding the label . 
 This also questions what could be the types of subids -we currently refer to -but that could also be DIDs ( cf ) or JWK thumbprint -or a unique identifier local to the AS : asuid ( suggestion to be used as an example instead of email , cf ) , this would be opaque ( and random ) to other systems but enough for a client to distinguish users ( just like using a database identifier )
Mailing list commentary: I ' m late to this conversation and confused by ' use of End - User ( his caps ) and subject . Are we talking about a DID for the subject , the end - user , or both ? To be clear , in my mind , the subject is in control of policies and capabilities at the GNAP AS . The end - user is in control of a client or user agent and a request to the AS . The end - user and client may or may not have any prior relationship with the AS . Adrian
Paragraph (version B):
When the AS is done interacting with the user, the AS interaction-
callback to the client instance using the redirect URL provided in
(2).  The redirect URL is augmented with an interaction reference
that the AS associates with the ongoing request created in (2) and
referenced in (4).  The redirect URL is also augmented with a hash
of the security information provided in (2) and (3).  The client
instance loads the verification information from (2) and (3) from
the session created in (1).  The client instance interaction-hash
based on this information and continues only if the hash
validates.  Note that the client instance needs to ensure that the
parameters for the incoming request match those that it is
expecting from the session created in (1).  The client instance
also needs to be prepared for the end-user never being returned to
the client instance and handle timeouts appropriately.
Paragraph (version B):
Subject identifier types requested by the client instance serve only
to identify the RO in the context of the AS and can't be used as
communication channels by the client instance, as discussed in
response-subject.
Paragraph (version A):
Note: the "sub_ids" and "assertions" request fields are independent
of each other, and a returned assertion MAY omit a requested subject
identifier.
Paragraph (version B):
Note: the "subject_types" and "assertions" request fields are
independent of each other, and a returned assertion MAY omit a
requested subject identifier.
Paragraph (version A):
REQUIRED.  Indicates the URI to send the RO to after interaction.
This URI MAY be unique per request and MUST be hosted by or
accessible by the client instance.  This URI MUST NOT contain any
fragment component.  This URI MUST be protected by HTTPS, be
hosted on a server local to the RO's browser ("localhost"), or use
an application-specific URI scheme.  If the client instance needs
any state information to tie to the front channel interaction
response, it MUST use a unique callback URI to link to that
ongoing state.  The allowable URIs and URI patterns MAY be
restricted by the AS based on the client instance's presented key
information.  The callback URI SHOULD be presented to the RO
during the interaction phase before redirect.
Paragraph (version A):
While it is expected that many APIs will have its own properties, a
set of common properties are defined here.  Specific API
implementations SHOULD NOT re-use these fields with different
semantics or syntax.  The available values for these properties are
determined by the API being protected at the RS.
Paragraph (version A):
OPTIONAL.  A list of the AS's supported identifiers.  The values
of this list correspond to possible values of the request-subject
of the request.
Paragraph (version B):
OPTIONAL.  A list of the AS's supported subject identifier types.
The values of this list correspond to possible values of the
request-subject of the request.