n-sakimura at nri.co.jp
Tue Jul 2 05:14:40 UTC 2013
In Messages, it is normatively defined that Issuer Identifier is an
Here is the quote from Section 1.2 Terminology of Messages
Verifiable identifier for an Issuer. An Issuer Identifier is a URL using
the https scheme that contains scheme, host, and OPTIONALLY, port number
and path components. (No query or fragment components MAY be present.)
It has been like that since 2011.
(2013/07/02 7:12), Mike Jones wrote:
> Breno and Naveen, what would it take for you to change your issuer string over time from "accounts.google.com" to "https://accounts.google.com"? If you ever want to support discovery, this change will need to happen sometime. Changing it earlier rather than later will also minimize the interop impact over time for clients that expect https:// to be present and choke on an issuer without it.
> Thank goodness we're doing interop now to catch these kinds of things early!
> I believe that Google eventually intends to publish a discovery document, for what it's worth - am I correct guys?
> Thanks all,
> -- Mike
> -----Original Message-----
> From: John Bradley [mailto:ve7jtb at ve7jtb.com]
> Sent: Monday, July 01, 2013 3:05 PM
> To: Mike Jones
> Cc: openid-specs-ab at lists.openid.net List
> Subject: Re: [Openid-specs-ab] iss
> 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.
>> -- 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 184.108.40.206 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.
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
Nat Sakimura (n-sakimura at nri.co.jp)
Nomura Research Institute, Ltd.
The information contained in this e-mail is confidential and intended
for the named recipient(s) only.
If you are not an intended recipient of this e-mail, you are hereby
notified that any review, dissemination, distribution or duplication of
this message is strictly prohibited. If you have received this message
in error, please notify the sender immediately and delete your copy from
More information about the Openid-specs-ab