Some of my Ping CTO colleagues and I recently had an email thread discussing the relevance of OpenID Connect's dynamic trust and configuration mechanisms to the enterprise.
Rather than trying to extract from that email thread the main points and conclusions, I'll take the easy route and simply paste the thread here, lightly annotated.
Rest assured that Pam's profanity, Han's use of obscure Dutch idioms, and John's poor grammar have been corrected.
I kicked off the thread. I often ask questions of my colleagues even when I already know the answer. Makes them feel valued.
On 4/15/14, 5:47 PM, Paul Madsen wrote:
What are the use cases where Connect's support for dynamic trust & configuration mechanisms are relevant to enterprise? (where, given the existence of business relationships, perhaps naively they would seem less relevant than in consumer world)
* initial configuration as part of workflow, i.e. after subscribing to SaaS * automatic updating * key rollover?
Hans contributes his '2 cents'. As Hans is Dutch, the currency is Euros. But
don't discount his input just for that.
The mention of key rollover is timely given HeartBleed......
1) SaaS app figures out the home domain of the tenant.
2) SaaS app finds the discovery document in a well-known location at the domain.
---- learns that dynamic client reg is supported, where the reg endpoint is etc.
3) SaaS app makes a request to the Registration endpoint, asserting a bunch of capabilities, and optionally including an access token provided out of band in the Authorization Header.
4) AS returns a client_id, optional secret, confirms the capabilities approved, and optionally returns a configuration endpoint URI and access token for making future changes.
Interestingly, although section 4 of the dynamic registration doc talks about viewing and update through the configuration endpoint, the sections documented only speak to a read operation, not an update operation. So if the AS supported alg1 and alg2, and originally the app only supported alg1, but then upgraded to support alg2, I don't think the exact request that would be made is specified currently. But will have to go re-read to be sure I'm not just missing something.
John temporarily stops vacuuming his pool in sunny Chile to join in.
He gives the editor's insider view on the registration spec limitation that Pam pointed out.
He suggests that the enterprise could maintain control of SaaS onboarding (as opposed to allowing 'open registration') by controlling the issuance of access tokens - these manually provided to the SaaS in order to authenticate the registration messages.
On 4/15/14, 2:54 PM, John Bradley wrote:
Connect and OAuth dynamic registration don't have update or delete semantics defined. We did initially define update and delete for it but that was pulled into a separate ID to allow registration to progress.
For the workflow, the enterprise can give the SaaS an access token to register if it doesn't want to have open registration.
If the enterprise allows open registration they may or may not need to tell the enterprise what their client_id is to allow extra attributes to be released.
In most cases, people worry more about the RP trusting the IdP. In the Connect Discovery case they just need to know the Issuer "iss" and from that they can get all the other information they need to do Connect.
In the case of IdP, they may or may not care who the potential RP is. If lots of sites start taking Connect than I imagine that people will leave registration open to make it convenient for their employees to login at new sites without having to go through a long IT approval process, but depending on trust-marks shown by the RP more or less scopes may be available. There might also be a blacklist.
It remains to be seen if enterprise IdP want to limit RP due to the pain of setting up connections or some real policy reason.