[Openid-specs-ab] WGLC for the Migration spec. towards the implementer's draft

Justin Richer jricher at mitre.org
Tue Jul 29 14:21:26 UTC 2014


I get that argument, but on the other hand if someone's doing a 
transition then they've probably already got an OpenID 2 client library 
that will handle the discovery.  Thus, my thought was "you hand me an 
OpenID 2 identifier in the URL and I do OpenID 2 discovery on that URL 
just like normal and look for the right value". It's the same 
justification for using the issuer value in the other direction, you 
make use of existing discovery mechanisms instead of inventing something 
new.

For someone who has only an OIDC stack to deal with for whatever reason, 
the JSON alternative is a really nice simplification.

  -- Justin

On 07/28/2014 04:04 PM, John Bradley wrote:
> Having it in the xrd for openID 2 clients looking to see if an account 
> has a connect IdP is fine,  but expecting Connect libs to find that is 
> going to be too much.
> If we were to add the iss to the XRD we might as well add a login hint 
> as well.  That way a smart openID 2 lib could find iss and login hint 
> and cut over to Connect for the login.
>
> For someone starting with Connect and working backwards then the 
> simple JSON works best.
>
> Nothing to say we can't recommend IdP add both, however the more we 
> ask them to do the less likely they are to do anything.
>
> John B.
> On Jul 28, 2014, at 2:18 PM, Justin Richer <jricher at mitre.org 
> <mailto:jricher at mitre.org>> wrote:
>
>> I'd go with either case 1 (keep it simple) or with just adding a 
>> field into the server's existing XRD/discovery documents. The problem 
>> with the latter is that you've got HTML-based discovery, XRD with 
>> content negotiation, directed identifiers, and a bunch of other 
>> screwy bits.
>>
>> So while the XRD-kindof solution (distinct from the JRD/case2 Nat 
>> mentioned) would be more complete, it's probably overkill and doesn't 
>> actually help the developers.
>>
>>  -- Justin
>>
>> On 07/28/2014 12:43 PM, Nat Sakimura wrote:
>>> And which formatting options do you guys prefer?
>>>
>>> Sent from my iPad
>>>
>>> On 2014/07/28, at 11:18, Torsten Lodderstedt 
>>> <torsten at lodderstedt.net <mailto:torsten at lodderstedt.net>> wrote:
>>>
>>>> +1
>>>>
>>>> Am 28.07.2014 um 18:02 schrieb John Bradley <ve7jtb at ve7jtb.com 
>>>> <mailto:ve7jtb at ve7jtb.com>>:
>>>>
>>>>> I think the most useful thing is to return the Connect issuer.   
>>>>> Returning keys directly will break for those IdP that rotate there 
>>>>> signing keys on a regular basis.
>>>>>
>>>>>
>>>>> On Jul 28, 2014, at 11:34 AM, Nat Sakimura <sakimura at gmail.com 
>>>>> <mailto:sakimura at gmail.com>> wrote:
>>>>>
>>>>>> So, the reason to do the discovery on the OpenID 2.0 Identifier 
>>>>>> is to detect an attacker setting up an OpenID Connect OP that 
>>>>>> returns an ID Token with the openid2_id of the victim to 
>>>>>> impersonate him.
>>>>>>
>>>>>> We discussed at the F2F at ForgeRock back in March about it and 
>>>>>> generally agreed that returning a public key from the openid2_id 
>>>>>> would mitigate the issue, and thus I wrote it that way.
>>>>>>
>>>>>> Obviously, returning jwks_uri or iss would do the job though it 
>>>>>> will require progressively more requests.
>>>>>> When I wrote the draft, I opted for the least requests option.
>>>>>> Having pointed out by Justin, though, if you think of it, perhaps 
>>>>>> it does not involve more requests at all.
>>>>>> It may not even involve the keys: if the iss returned by the 
>>>>>> openid2_id machies that of the ID Token,
>>>>>> it may just suffice as a "light weight" verification. In this 
>>>>>> case, which do we want to return?
>>>>>>
>>>>>> Case 1)
>>>>>>    HTTP/1.1 200 OK
>>>>>>    Content-Type: application/json
>>>>>>
>>>>>>    {
>>>>>>     "iss":"https://server.example.com  <https://server.example.com/>"
>>>>>>    }
>>>>>> OR
>>>>>>
>>>>>> Case 2)
>>>>>>    HTTP/1.1 200 OK
>>>>>>    Content-Type: application/jrd+json
>>>>>>
>>>>>>    {
>>>>>>     "subject": "https://example.com/joe",
>>>>>>     "links":
>>>>>>      [
>>>>>>       {
>>>>>>        "rel": "http://openid.net/specs/connect/1.0/issuer",
>>>>>>        "href": "https://server.example.com  <https://server.example.com/>"
>>>>>>       }
>>>>>>      ]
>>>>>>    }
>>>>>>
>>>>>> FYI, I prefer Case 1), because all the response to the openid2_id 
>>>>>> can return the same thing, and simple,
>>>>>> but that is only my own opinion.
>>>>>>
>>>>>> Now, there is one issue that are common to all three options.
>>>>>> Many OpenID 2.0 Identifiers are not https but http.
>>>>>> This means that the response may be tampered.
>>>>>> Do we want to take care of it?
>>>>>> Unfortunately, there is no guarantee that http openid2_id and 
>>>>>> https openid2_id points to the same person.
>>>>>> So, a simple replacement of the scheme does not work in principle.
>>>>>> We may mandate it for the Migration spec support, but I do not 
>>>>>> know if that is feasible at all.
>>>>>>
>>>>>> Any opinion?
>>>>>>
>>>>>> Nat
>>>>>>
>>>>>>
>>>>>> 2014-07-28 8:56 GMT-04:00 Richer, Justin P. <jricher at mitre.org 
>>>>>> <mailto:jricher at mitre.org>>:
>>>>>>
>>>>>>     I'm not seeing the purpose in returning the JWK set from the
>>>>>>     OpenID 2 identifier URI, especially if the client is supposed
>>>>>>     to be doing regular OIDC to validate the ID Token anyway (and
>>>>>>     will therefore fetch the issuer's jwks_uri). Can you please
>>>>>>     explain to me what this step is supposed to be accomplishing?
>>>>>>
>>>>>>     Is the idea that the client would be able to verify that the
>>>>>>     claimed OpenID 2 identifier actually points to the given
>>>>>>     issuer, basically completing the round-trip verification? If
>>>>>>     that's the case, then wouldn't it make more sense to return
>>>>>>     the OpenID Connect issuer from the OpenID 2 discovery steps?
>>>>>>     Then from the issuer you can determine the key, just like
>>>>>>     normal. This would allow for a forward-looking discovery
>>>>>>     launching point ("all I have is this OpenID 2.0 URI, what's
>>>>>>     the OpenID Connect process to start here?") well as a
>>>>>>     backward-looking verification for the claim.
>>>>>>
>>>>>>      -- Justin
>>>>>>
>>>>>>     On Jul 27, 2014, at 9:35 AM, Nat Sakimura <sakimura at gmail.com
>>>>>>     <mailto:sakimura at gmail.com>> wrote:
>>>>>>
>>>>>>>     Actually, the OpenID 2.0 Identifier URL returns JWK Set. It
>>>>>>>     should probably be more explicit than to say
>>>>>>>     application/jwk-set+json.
>>>>>>>
>>>>>>>     Good point about reutrning jwk_uri instead of the JWK Set.
>>>>>>>     The downside is that you have to make two calls, but it is
>>>>>>>     only once per RP/OpenID 2.0 Identifier pair, so it probably
>>>>>>>     is OK.
>>>>>>>
>>>>>>>     What do others think?
>>>>>>>
>>>>>>>     Nat
>>>>>>>
>>>>>>>
>>>>>>>     2014-07-26 11:52 GMT-04:00 Torsten Lodderstedt
>>>>>>>     <torsten at lodderstedt.net <mailto:torsten at lodderstedt.net>>:
>>>>>>>
>>>>>>>         Hi Nat,
>>>>>>>
>>>>>>>         I just read the spec (for the first time) and think the
>>>>>>>         concept is generally sound. I'm wondering a bit about
>>>>>>>         the way the client obtains the OP's public key. The GET
>>>>>>>         request on the OpenID 2.0 Identifier URL directly
>>>>>>>         returns the JWK. I would suggest to just return the
>>>>>>>         jwk_uri, in the same way openid connect discovery does
>>>>>>>         it. This way this GET request is static (even with key
>>>>>>>         rotation in place) and the OP can reuse the existing
>>>>>>>         functionality to publish its public keys (including
>>>>>>>         support for multiple keys in case of rotation).
>>>>>>>
>>>>>>>         What do you think?
>>>>>>>
>>>>>>>         kind regards,
>>>>>>>         Torsten.
>>>>>>>
>>>>>>>         Am 26.07.2014 07:44, schrieb Nat Sakimura:
>>>>>>>>         Thanks to Edmund Jay, the examples are now fixed.
>>>>>>>>         This is to initiate the WG Last Call.
>>>>>>>>         Please review the document and file issues if there are
>>>>>>>>         within a week.
>>>>>>>>         Once all the issues are resolved, we will go to the
>>>>>>>>         implementer's draft public review period for 45 days.
>>>>>>>>
>>>>>>>>         Nat
>>>>>>>>
>>>>>>>>         -- 
>>>>>>>>         Nat Sakimura (=nat)
>>>>>>>>         Chairman, OpenID Foundation
>>>>>>>>         http://nat.sakimura.org/
>>>>>>>>         @_nat_en
>>>>>>>>
>>>>>>>>
>>>>>>>>         _______________________________________________
>>>>>>>>         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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>     -- 
>>>>>>>     Nat Sakimura (=nat)
>>>>>>>     Chairman, OpenID Foundation
>>>>>>>     http://nat.sakimura.org/
>>>>>>>     @_nat_en
>>>>>>>     _______________________________________________
>>>>>>>     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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -- 
>>>>>> Nat Sakimura (=nat)
>>>>>> Chairman, OpenID Foundation
>>>>>> http://nat.sakimura.org/
>>>>>> @_nat_en
>>>>>> _______________________________________________
>>>>>> 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 
>>>>> <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
>>
>> _______________________________________________
>> 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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140729/6d203b54/attachment-0001.html>


More information about the Openid-specs-ab mailing list