[Openid-specs-ab] Determining OP Issuer

John Bradley ve7jtb at ve7jtb.com
Thu Apr 4 01:00:53 UTC 2013

We don't have unsolicited assertions.   That violates OAuth 2.   We do have a way for a IdP to initiate a authentication request from a RP.

I can't think of a situation where a client is going to get a token from a unknown issuer that would not be in error.  

If the RP is not properly using state to prevent cross site attacks you could  do the lookup based on the issuer and that would work.
Though I suspect we may not want to encourage people to do that as it leaves them open to other attacks.

If the request to initiate login is coming from a form on the site where the user is entering the email the RP needs to do WF as the IdP could be configured on a per user basis.
I made a proposal to drop the per user lookup at one point and go strait to the /.well-known/openid-configuration based on the domain but it was rejected by the WG.  

If we were doing that we wouldn't need WF discovery at all.

The exception to this is where the RP is using account chooser and gets the account and issuer, in that case though we don't talk about account chooser in the connect spec, I would expect a RP to use the issuer/IDP given to it by account chooser and get /.well-known/openid-configuration  based on that skipping WF lookup that will be highly cacheable.

The one disconnect we have with account chooser is that Google is currently putting in google.com  or facebook.com as the value rather than https://google.com so the RP currently needs to do some lookup and mapping on there side.  I expect that for connect IdP it would be best to put in the issuer such as https://salesforce.com/customer1 so the RP can use the value directly to get the correct issuer info.    Also hosted domains on apps for domains will need to work that way, as WF discovery doesn't support them.

So I still think the client gets the info before the request and caches it, then looks the issuer up in the cached info.  if there is no cached info for the issuer that is an indication something is wrong.

John B.

On 2013-04-03, at 9:19 PM, Tim Bray <tbray at textuality.com> wrote:

> I’m looking at http://openid.net/specs/openid-connect-discovery-1_0.html
> and in section 4.1 it says “The Client would make the following request to the Issuer to get the Configuration information” where the Issuer is discovered using WebFinger as described in Section 2. 
> I’m wondering if it might also make sense to determine the issuer by reading it out of the ID Token you just received.  The “iss” claim is required, after all.  
> Once again, I’m suffering from having missed the first seven eighths of this discussion.  I’m looking for a deterministic way for an RP to validate an ID Token.  If I read Section 2 correctly, the recommended way to do this is to start with the email address and figure out the issuer from that using WebFinger.  
> We’re using ID Tokens as unsolicited assertions that this we’ve authenticated a person, identified inside the token, by sub/email. If I want to be convinced that the issuer really asserted that the sub is authenticated, must I go sideways through WebFinger, couldn't I just go get the /.well-known/openid-configuration from the issuer, fetch the keys, and do it that way?  -T
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130403/9f94f1f5/attachment-0001.html>
-------------- 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/20130403/9f94f1f5/attachment-0001.p7s>

More information about the Openid-specs-ab mailing list