Lessons Learned draft 11 initial version

Here are my learnings from implementing XAuth -11

claims.[schema] works well to determine if claims schema is supported
authorization.type worked well to detect the authorization schema
separate DBs for client.id (registered clients) and client.handle (dynamic clients) keeps these similar, but different storage systems independent. Have to detect which type of client, but code was not onerous.
separate identifiers for dynamic and registered clients made it easy to have policy that let registered clients do things not available for dynamic clients (write access) and to require Grant Verification.
interaction modes made it easy to evaluate what would happen in interaction and decide what was allowed and not allowed
representing grants and authorizations as URIs and using methods for different APIs made routing to different modules simple. Adding a new API, Grant Verification was simple.
the top level objects made it easy to decompose validating and processing user, client, interaction, claims, and authorizations
warnings about ignored parameters looks useful, but coding it is brittle - JSON Schema may make it declarative
once a decoded JOSE token was available, it was simple to acquire the embedded JWK for a dynamic client
Grant and AZ ids in URI made it easy to return 404 early. Also made it easy to get client key.

Implementation stored registered and dynamic clients in two different databases. Code has to switch between the two. For simpler implementations store client.id and client.handle in same DB.
space separated scopes from OAuth 2.x is a coding thunk
OIDC claims having a null value is a thunk. Had to use hasOwnProperty instead of just testing value
claims.oidc.userinfo.mail is a long path to ask for a claim. Perhaps have oidc_userinfo and oidc_id_token?
separate top level objects for authorization and authorizations seems clumsy - perhaps detect plurality by detecting 'type' property? 'type' would be reserved for clients to not use. If no 'type', then each property is a separate authorization request. Or always have plural, but then an extra level for the common, single authorization use case.
having a '-' in a property name is messy in JS
peaking into JSON or decoding JOSE object to find client info in Create Grant is required before authentication can happen. Took a while to figure out the right way to structure routing and middleware.
JSON Schema looks like it may simplify input JSON validation. Also useful for validating responses in automated testing. IETF IDs have not been picked up in a WG so far.
My HTML skills suck
My ES6 knowledge is lacking