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

Mon Jul 28 16:05:12 UTC 2014

Hi John,

I actually agree. What do you think of the format?

Also, do you want to take care of the "http" tampering problem that I
explained in the previous mail?
If so, how?

2014-07-28 12:02 GMT-04:00 John Bradley <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> 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"
>   }
>
> 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"
>      }
>     ]
>   }
>
>
> 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>:
>
>>  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> 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>:
>>
>>> 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 listOpenid-specs-ab at lists.openid.nethttp://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
>> 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
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140728/c4e31ffb/attachment.html>