[Openid-specs-ab] iss

[John Bradley]

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

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