[Txauth] updated draft-hardt-xauth-protocol (-11) and an implementation!

[Dick Hardt <[e-mail]>]

I have updated the draft based on my implementation experience:

https://tools.ietf.org/html/draft-hardt-xauth-protocol-11

(note that the links at the top of the page are messed up -- I managed to
break the IETF tool)

I also updated the JOSE spec

https://tools.ietf.org/html/draft-hardt-gnap-jose-01

Here is the implementation in nodejs:

https://github.com/dickhardt/XAuth-poc

I implemented a CLI client that uses the indirect interaction mode, and a
web client that uses the redirect interaction mode.
The PoC supports no client authentication, and the proposed JOSE client
authentication mechanism.

The CLI client supports a QR code scan, or a -f flag can be set to fake out
the user -- handy for development.

All the protocol call and signing work is inline in the clients. I have not
made an attempt to create a module to support the protocol client side.

I wrote up some learnings here:

https://github.com/dickhardt/XAuth-poc/wiki/Lessons-Learned---draft-11---initial-version

Copy and pasted below:
Confirmations:

   - 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.

<https://github.com/dickhardt/XAuth-poc/wiki/Lessons-Learned---draft-11---initial-version#lessons>
Lessons

   - 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
   - parsing and peaking into JSON or decoding the JOSE object to find
   client info in Create Grant is required before authentication can happen.
   Took a while to figure out the right order to structure routing and
   middleware.
   - JSON Schema <https://json-schema.org/> 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