Draft: draft-ietf-gnap-core-protocol

Commentary: and 
 Requesting OpenID Connect Claims :  's note : I 'm not a fan of GNAP defining how OIDC would work at all and would rather that work be done by the OIDF in an extension . However , I think it is important for discussion to see this kind of thing in context with the rest of the protocol , for now . In the future , I would anticipate this would be defined by the OIDF as a relatively small but robust identity layer on top of GNAP . 
 Is it worth adding a note in this section of the document saying that this section may be removed before final publication ? 
 Editors recommend removing this section from the core document to allow for future extension and compatibility layer with OpenID Connect . 
 Requesting OpenID Connect Claims :  's note : In order to use the " claims " parameter as defined in OIDC , we have to violate the principle of orthogonality in Section 2.9 . An alternative approach would be to split up the portions of the claims request , so that " id_token " claims would go into the " subject " field and " userinfo " claims would go into the " resources " request , but this violates the original field definition from OIDC and gets into the territory of defining an identity schema request . This approach would also invalidate extensions to the " claims " standard as each " target " would need to have its own separate mapping to some part of the  protocol . 
 This is informational , should follow the fate of
Paragraph (version A):
Identifies the identity claims to be returned as part of an OpenID
Connect claims request.
Paragraph (version A):
Subject identifiers requested by the RC serve only to identify the RO
in the context of the AS and can't be used as communication channels
by the RC, as discussed in response-subject.  One method of
requesting communication channels and other identity claims are
discussed in request-oidc-claims.
Paragraph (version B):
Subject identifiers requested by the RC serve only to identify the RO
in the context of the AS and can't be used as communication channels
by the RC, as discussed in response-subject.
Paragraph (version A):
If the RC and AS both support OpenID Connect's claims query language
as defined in OIDC Section 5.5, the RC sends the value of the OpenID
Connect "claims" authorization request parameter as a JSON object
under the name "claims" in the root of the request.
Paragraph (version A):
The contents of the "claims" parameter have the same semantics as
they do in OpenID Connect's "claims" authorization request parameter,
including all extensions such as OIDC4IA.  The AS MUST process the
claims object in the same way that it would with an OAuth 2 based
authorization request.
Paragraph (version A):
Note that because this is an independent query object, the "claims"
value can augment or alter other portions of the request, namely the
"resources" and "subject" fields.  This query language uses the
fields in the top level of the object to indicate the target for any
requested claims.  For instance, the "userinfo" target indicates that
a returned access token would grant access to the given claims at the
UserInfo Endpoint, while the "id_token" target indicates that the
claims would be returned in an ID Token as described in response-
subject.
Paragraph (version A):
While request-oidc-claims specifies one such method, other identity
protocols could also be used on top of GNAP to convey this
information and the details of an identity protocol and associated
schema are outside the scope of this specification.
Paragraph (version B):
The details of an identity protocol and associated schema are outside
the scope of this specification.