[Openid-specs-ab] Determining OP Issuer

[Justin Richer]

As I read it (and as I've been implementing it), there are really two 
steps to the OpenID Connect discovery process.

Step 1: Find out the "issuer"

If the user is typing something in to a web form, you use Webfinger to 
turn what they typed into an issuer URL. You could bypass this step in 
several ways:
  - by just going straight to a pre-configured URL (if you know who you 
want to talk to)
  - by pulling the "iss" claim out of a presented id_token
  - magic


Step 2: Find out the server configuration (endpoints, keys, etc) for a 
given issuer

This is where the "GET {iss}/.well-known/openid-configuration" step 
comes into play. You could bypass this also by statically configuring 
connection information, if you have it.



So to answer Tim's question as I understand it, you can easily bypass 
step 1 if you already have the issuer, but you probably won't bypass 
step 2. You validate the signature of the token by checking its {iss} 
field, seeing if it's an issuer you trust, then getting the key for that 
issuer and doing math to it.

  -- Justin

On 04/03/2013 09:00 PM, John Bradley wrote:
> 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 <http://google.com>  or facebook.com 
> <http://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 
> <mailto: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 
>> <mailto:Openid-specs-ab at lists.openid.net>
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
> _______________________________________________
> 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/20130404/f20e1d53/attachment.html>