[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.html>
More information about the Openid-specs-ab
mailing list