Michael.Jones at microsoft.com
Mon Jul 1 19:52:14 UTC 2013
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.
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 18.104.22.168 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.
More information about the Openid-specs-ab