jricher
commented
2 years ago 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.
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.