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

Justin Richer jricher at mitre.org
Mon Jul 28 18:18:04 UTC 2014


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

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


More information about the Openid-specs-ab mailing list