[Openid-specs-ab] iss

Mike Jones Michael.Jones at microsoft.com
Mon Jul 1 22:12:10 UTC 2013


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.

{"iss":"accounts.google.com",
 "at_hash":"uqf7---aXGGK86s8No5igw",
 "email_verified":"true",
 "email":"ve7jtb at ve7jtb.com",
 "azp":"412063239660.apps.googleusercontent.com",
 "hd":"ve7jtb.com",
 "sub":"113758384073095653585",
 "aud":"412063239660.apps.googleusercontent.com",
 "iat":1372704073,
 "exp":1372707973}

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 2.1.2.1 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.
> 
> 
> 



More information about the Openid-specs-ab mailing list