Change:
Additional fields are defined in the IANA-client-instance. <ins> 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. </ins> The client instance MUST prove possession of any presented key by the "proof" mechanism associated with the key in the request.  Key proofing methods are defined in the IANA-key-proof-methods and an

Discussion:
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 doesn'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 doesn'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 don'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 isn'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.