[Openid-specs-ab] A few queries about OpenID Connect
glenn at welcomer.me
Mon Aug 4 00:20:45 UTC 2014
Thanks for the info John! Has set a few things straight in my mind, and
given me a few more things to ponder/look into further.
- Glenn / devalias
On 1 August 2014 06:43, John Bradley <ve7jtb at ve7jtb.com> wrote:
> On Jul 23, 2014, at 12:55 AM, Glenn Grant <glenn at welcomer.me> wrote:
> Hopefully this is the right place to ask this, was directed here by Thomas
> I have a couple of queries that weren't clear to me after reading through
> the specs and I was wondering if someone here might be able to help me out.
> * Can a single OpenID Provider (OP) manage separate contexts (eg.
> different unrelated/loosely related websites)?
> - This would imply to me yes: "OpenID Connect supports multiple Issuers
> per Host and Port combination." ?
> I think you are trying to ask if a single host can have multiple issuers
> The answer is yes that a issuer is a URI containing a optional path
> A host https://example.com night have several issuers hosted on it.
> Each issuer has a separate discovery document describing the endpoints for
> that issuer.
> They can be pointed at separate endpoints or the same ones depending on
> design. as an example the authorization endpoints might be
> https://example.com/authorize?tennent=1 for tennent1
> https://example.com/authorize?tennent=2 for tennent2
> Google for example is doing something like that for google apps domains.
> * Is it possible to externalise the userinfo endpoint from the OP core?
> - This is probably an implementation detail more than a spec thing, but I
> assume some of you would be familiar with the MITREid implementation.
> In principal the only requirement is that the user info-endpoint be able
> to accept access tokens from the IdP and produce the information for the
> correct user.
> * The spec makes reference to a 'Claim Provider', but doesn't really
> detail what is required to be one. Is it possible/how would one go about
> implementing a 3rd party claim provider, and how would you authorise to it
> (would it have to be an RP, or is it possible to implement arbitrary auth
> methods that it requires; eg to turn a non OpenID connect API into a Claim
> A claim provider is a OAuth 2 protected resource that returns claims in
> the JSON format and accepts access tokens provided by user info endpoint.
> The user info endpoint may produce signed JWT or perhaps get a access
> token from the claim provider via some sort of token exchange.
> If I were doing that bit of the spec again, I would probably also return a
> token endpoint for the claim provider and have the client exchange a JWT
> assertion for a access token to then use to request the resource. What we
> have works but may need to be refined as people get more experience with
> distributed claims.
> * If a single OP has 2 unique identities (on seperate issuers) for user A,
> (A1 & A2), is there a way to make an aggregated claim with details from
> both, and how/where would you obtain/store the authorisations to do so? (or
> would it be a better concept to implement a separate scope for each
> 'seperate endpoint' (eg. 2 businesses running on the same OP))
> 2 OP running on the same server should be separate.
> A OP is a issuer, you are perhaps trying to create a relationship between
> issuers, that is beyond the scope of the spec, and likely a very difficult
> UI problem.
> People are more likely to understand multiple persona via a single
> issuer/OP, Yahoo I think tried that but I suspect it mostly confused
> I guess the question is once you have pairwise identifiers to stop cross
> site correlation and fine-grained attribute release, do people really want
> to manage multiple identities at the same RP?
> One thing we left open is the possibility of other identifier types like
> ephemeral (single use), you could use that to release some one time set of
> claims like over 18 etc.
> However that has never made it beyond theoretical discussions. Real
> deployments tend to avoid things that complicate there lives and are hard
> for users to understand.
> John B.
> Hopefully those questions make sense (they're a little bit of a brain dump)
> Thanks so much!
> - Glenn / devalias
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab