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.
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.
> -- 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 126.96.36.199 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.
> John B.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4507 bytes
Desc: not available
More information about the Openid-specs-ab