[OpenID] discovery url vs issuer

[John Bradley]

I suspect that you are going to be better off with the interop testing list. 

Information on testing and subscribing to the list are at this link.

http://osis.idcommons.net/wiki/OC5:OpenID_Connect_Interop_5


To answer the question, yes they must all match.   The value of issuer is the uri before appending /.well-known/openid-configuration to the issuer per sec 4 of discovery.

The value returned by the webfinger element with the rel member value of http://openid.net/specs/connect/1.0/issuer  is the issuer identifier and not the location of the meta-data.

That is in Sec 2 of Discovery.  

Perhaps in a future errata we might add a note to make that clearer in Sec 2.

So typically  a iss is a value like https://example.com

Webfinger would return that value.

To retrieve the meta-data you append /.well-known/openid-configuration and do a GET on https://example.com/.well-known/openid-configuration

That would have a “issuer” element of https://example.com

The id_tokens issued will have a “iss” element of https://example.com

In a multi tenant situation you might have a path component eg https://example.com/tennent_1  for tenant 1.

You are now going to ask why the whole string for the meta-data location is not used as the issuer.

We did debate that at teh time and the answer is size.

Returning the fixed string /.well-known/openid-configuration in every id_token is a unproductive waste of space and makes it harder to keep under URI length limits.

Regards
John B.


> On Jan 27, 2016, at 7:38 PM, Paul Hethmon <paul.hethmon at clareitysecurity.com> wrote:
> 
> First, I haven’t seen any traffic from this list since joining a month ago, so if I’m off topic, please let me know.
> 
> I am beginning conformance testing and seeing an unexpected error from the conformance tool. My setup is that my issuer has a value like:
> 
> 	https://idp.clareitystore.net/idp/shibboleth
> 
> I’ve got my metadata at this URL:
> 
> 	https://idp.clareitystore.net/idp/openid/configuration
> 
> With support for appending the value “.well-known/openid-configuration”. That returns a metadata document with my issuer value as above.
> 
> Testing gives me:
> 
> 0.000465 ------------ DiscoveryRequest ------------
> 0.000496 Provider info discover from 'https://idp.clareitystore.net/idp/openid/configuration'
> 0.000503 --> URL: https://idp.clareitystore.net/idp/openid/configuration/.well-known/openid-configuration
> 0.161675 [ERROR] IssuerMismatch:'https://idp.clareitystore.net/idp/openid/configuration' != 'https://idp.clareitystore.net/idp/shibboleth'
> 
> So it’s obvious the tool is requiring the issuer value to be where the discovery request goes to and that it match.
> 
> Where in the spec does it say that? I’m not finding it. In the OpenID Connect Discovery 1.0 (errata set 1), section 3 says:
> 
> issuer
> REQUIRED. URL using the https scheme with no query or fragment component that the OP asserts as its Issuer Identifier. If Issuer discovery is supported (seeSection 2), this value MUST be identical to the issuer value returned by WebFinger. This also MUST be identical to the iss Claim value in ID Tokens issued from this Issuer.
> 
> Is that where the match comes from? If I do Discovery, then the WebFinger value MUST match? Since that value is the location of the metadata, then that now means that my Issuer value must be the actual URL for Discovery.
> 
> From a legacy perspective, it would be better for me to not have the issuer be the URL for the Discovery metadata location, but it if must match in that way, then either I have to change a lot of identifiers or drop Discovery.
> 
> thanks,
> 
> Paul
> 
> -----
> Paul Hethmon
> Chief Software Architect
> paul.hethmon at clareitysecurity.com
> 
> 
> _______________________________________________
> general mailing list
> general at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general

-------------- 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-general/attachments/20160127/a0729cce/attachment.p7s>