Draft: draft-ietf-gnap-core-protocol

Commentary: Built To edit notification comments on pull requests , go to your . 
 In Sec . 2.3 we say , " The contents and format of this field are up to the AS . " Assuming no pre - registration , this does n't make sense , because the Client has not interacted with the AS yet . And in fact if pre - reg has taken place , we say this field should be ignored ! Maybe say instead : The content of this field is typically statically configured , and MAY be used as a hint to the AS . 
 The question here is really " pre - registration of what " . When we talk about pre - registration in GNAP , we 're really referring to pre - registration of specific individual instance keys , and associating those keys with specific attributes . However , things like the class identifier can be used alongside of other fields to make sense of the client 's registration request and verify it . Here 's a strawman example : you 've got a mobile banking ecosystem . All keys for clients are issued as certificates signed by the CA at the time of installation on the devices . The AS does n't get told about every single key , however , it just has the root CA cert , like usual PKI stuff . There 's several kinds of banking apps in this ecosystem . When a client shows up , it presents its individual key along with the class identifier for the kind of app that it is . The AS sees that the cert is issued by the CA and that the class identifier maps the app to one specific set of attributes , including rights it 's allowed to ask for . Now before you ask -- yes you could bake all of that into the certificate itself with its own special fields , and I 'm sure some will do exactly that . But there 's no reason to couple GNAP to that specific kind of PKI solution , though we can use it . There are other ways to remix these functions , and I do n't believe that GNAP should take a hard stance on that . 
 Another consideration : while the client instance may not have contacted the AS yet , the client software can be written with a specific AS in mind . Like a set top box with a class ID claiming to be " FooBarTV version 4 " , which tells the AS what kind of thing is claiming to connect . This is n't a trustworthy secret value but it can be used by the AS as part of its policy . The editors will add more text for describing use cases like these to help explain what the field is for .
Paragraph (version B):
Both the "display" and "class_id" are self-declarative and thus the
AS SHOULD exercise caution in their interpretation, taking them as a
hint but not as absolute truth.  The "class_id" field can be used in
a variety of ways to help the a variety of ways to help the AS make
sense of the particular context in which the client instance is
operating.  In corporate environments, for example, different levels
of trust might apply depending on security policies.  This field aims
to help the AS adjust its own access decisions for different classes
of client software.  It is possible to configure a set of values and
rules during a pre-registration, and then have the client instances
provide them later in runtime as a hint to the AS.  In other cases,
the client runs with a specific AS in mind, so a single hardcoded
value would acceptable (for instance, a set top box with a "class_id"
claiming to be "FooBarTV version 4").  While the client instance may
not have contacted the AS yet, the value of this "class_id" field can
be evaluated by the AS according to a broader context of dynamic use,
alongside other related information available elsewhere (for
instance, corresponding fields in a certificate).  If the AS is not
able to interpret the class_id field, it SHOULD return an
"invalid_client" error or choose to return lesser levels of
privileges.  See additional discussion of client instance
impersonation in security-impersonation.