Explicit process for getting from registration JWT --> trust decision

[jmandel]

You'll be able to do trust chains with JWK, one way is to incorporate the certificate-style inputs in the JWK directly. The other way is to inherit the trust chain used in the HTTPS request.

I think I just need details here about each step in the process, from:

1.  SP sees an app present a registration JWT
... some steps here involving HTTPs, cert chains, URIs...
n. SP makes a trust decision and okays/denies the registration request

This includes guidance (if not mandated rules) about how to make a trust decision, based on certificate chains, HTTPs request context, etc -- in short whatever components I need to make the decisions (and whatever trust I need up-front) should be explicitly documented.

[jricher]

SP parses JWT, gets {iss}. If {iss} is trusted (configuration @ sp), it does:

GET {iss}/.well-known/bb/trustbundle.json

finds JWK endpoint, does:

GET {jwk-uri}

checks signature on JWT from given JWK. If it matches, do:

GET {iss}/.well-known/bb/clients.json#{sub}

Compare (exact string match? regex?) pre-registered values against dynamically provided values.

[jmandel]

Should we specify what happens for a Trust Bundle with multiple public keys?

[jricher]

They'd all be published in a JWK-set together at the Trust Bundle (same URI). We can specify that the token always include a "kid" field to make sure you're checking against the right key, and specify that all keys at a JWK set include a "kid" field as well. (it's optional in JOSE, we can make it a MUST)

[jmandel]

Perfect. (So GET {jwk-uri} is really GET {jwks-uri}).

[jricher]

Yes, that's what I actually meant. I think the document text has "jwks" and "JWK Set" in it -- if not, it should.

[jmandel]

You're right, it does. So all we need is the MUST on kid.