[Openid-specs-ab] A few queries about OpenID Connect

John Bradley ve7jtb at ve7jtb.com
Thu Jul 31 20:43:21 UTC 2014

On Jul 23, 2014, at 12:55 AM, Glenn Grant <glenn at welcomer.me> wrote:

> Heya,
> Hopefully this is the right place to ask this, was directed here by Thomas Hardjono.
> 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 component.
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 Provider)

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

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
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140731/dc990992/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4326 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140731/dc990992/attachment-0001.p7s>

More information about the Openid-specs-ab mailing list