[Openid-specs-ab] iss

John Bradley ve7jtb at ve7jtb.com
Mon Jul 1 22:04:56 UTC 2013

This was the id_token google issued.

 "email":"ve7jtb at ve7jtb.com",

Having them change issuer will I expect not be trivial.

It works but for discovery.  We could perhaps say that if it is a host and not a uri you prepend https: but that touches more places.

What they are doing is not incorrect per messages.

I need to check the other participants but I assume the ones that support discovery and registration won't have that issue.

John B.

On 2013-07-01, at 3:52 PM, Mike Jones <Michael.Jones at microsoft.com> wrote:

> Agreed.  We should apply the text from Discovery to the "iss" definition in Messages, etc.  That was always the intent, and we should be explicit to prevent interop problems down the road.
> Who is using a plain hostname?  We should notify them.
> 				Thanks,
> 				-- Mike
> -----Original Message-----
> From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of John Bradley
> Sent: Monday, July 01, 2013 12:45 PM
> To: openid-specs-ab at lists.openid.net List
> Subject: [Openid-specs-ab] iss
> In Messages we define iss as Issuer Identifier for the Issuer of the response. The iss value is a case sensitive string.
> In Discovery Section 3 we have:
> issuer REQUIRED. URL using the  scheme with no query or fragment component that the OP asserts as its Issuer Identifier
> So for discovery to work you need to be able to retrieve the meta-data from a well-known location for that issuer, so restricting issuer to a https: uri to make the mapping simple is sensible.
> However in the core spec iss could be any string as long as the client is manually configured with the correct information for endpoints and certificates.
> I note this because looking at the interop participants at-least one who is not supporting discovery is using a plain host name.
> Should we have a warning in messages that https: scheme URI are recommended issuer strings as they allow discovery and prevent name collisions.
> Certainly arbitrary strings can work as issuer for manual configuration though as we discovered in SAML that leads to interesting interop problems down the road.
> I see way to many SAML entityID of "test", "example.com", and "demo" in production.  collision resistance for issuer strings is important for interoperability.
> I have a feeling that the definition of issuer from JWT may be a touch to vague for messages.
> Thoughts?
> John B.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4507 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130701/fcccf2b2/attachment.p7s>

More information about the Openid-specs-ab mailing list