[Openid-specs-ab] Review Comments on Dyn Reg

[Brian Campbell]

Yeah, I'm okay with that. There probably is too much too it to try and
fit it in now.

Torsten and I had talked a bit about it in Vancouver. Seeing that one
point in his review reminded me of that and I just wanted to raise the
question - mostly for awareness. There's been a lot of posturing
recently about how OAuth/Connect are proliferating password usage. But
little has actually been done about it. Giving native clients a more
viable way to do asymmetric stuff, however, would be a legitimate step
to reducing password usage.

I would like to consider it as a future extension here and/or in OAuth
registration. And allow for rotation as well as options that let
either the AS or the client generate the keys. I realize the latter is
"better" but there's potentially real utility in the former.

On Fri, Nov 15, 2013 at 5:28 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:
> So leave it as an extension to be defined later once we have update to deal with key rotation.
>
>
> On Nov 15, 2013, at 9:15 AM, Richer, Justin P. <jricher at mitre.org> wrote:
>
>> Yeah, I get the functionality, and it makes sense intuitively, but it also seems like it'd be a bad decision to make last-minute because there's not really a good analogue elsewhere in the spec. (The other fields we've added to registration in the last 6 months have been parallel to those found in Discovery). And as you point out below, without any way to do an update natively in Connect's registration, there's no way to do key rotation. I can imagine there will be other issues that we haven't thought of yet.
>>
>> -- Justin
>>
>> On Nov 15, 2013, at 1:12 PM, John Bradley <ve7jtb at ve7jtb.com>
>> wrote:
>>
>>> The use is the same as jwks_uri but a push rather than a pull for native clients.
>>>
>>> Without it native clients are limited to only symmetric key for authentication and AS are also limited to only symmetric encryption to the client.
>>> Proof of possession is a future.
>>>
>>> That said I doubt that there will be a big demand for this in native apps, so doing it later as an extension for native apps is fine with me.
>>>
>>> John B.
>>>
>>>
>>>
>>> On Nov 15, 2013, at 8:51 AM, Richer, Justin P. <jricher at mitre.org> wrote:
>>>
>>>> It sounds too under defined at the moment, in my opinion -- especially for something as fundamental a security parameter as this. We can always extend/augment the fields in § 2.1 in the future after we get some people actually implementing it and trying it out.
>>>>
>>>> -- Justin
>>>>
>>>> On Nov 15, 2013, at 12:35 AM, Brian Campbell <bcampbell at pingidentity.com> wrote:
>>>>
>>>>> I could make one. It'd probably involve the introduction of a new
>>>>> registration parameter (jwks probably).
>>>>>
>>>>> The larger question for the group, I think, is if this is something
>>>>> that we should try to add at this point?
>>>>>
>>>>> On Thu, Nov 14, 2013 at 4:18 PM, Mike Jones <Michael.Jones at microsoft.com> wrote:
>>>>>> Is there a specific proposed text change?
>>>>>> ________________________________
>>>>>> From: Brian Campbell
>>>>>> Sent: 11/14/2013 5:50 PM
>>>>>> To: Torsten Lodderstedt
>>>>>> Cc: Openid-specs Ab; Mike Jones
>>>>>>
>>>>>> Subject: Re: [Openid-specs-ab] Review Comments on Dyn Reg
>>>>>>
>>>>>> I think Torsten raises a good question here. The jwks_uri is great for
>>>>>> clients that have a web server. But there's not really a good story
>>>>>> for native clients who want to use anything other than a shared secret
>>>>>> (for signatures, encryption or authentication to the token endpoint).
>>>>>>
>>>>>> Is it too limiting? Seems like it might be...
>>>>>>
>>>>>> On Wed, Nov 6, 2013 at 7:11 PM, Torsten Lodderstedt
>>>>>> <torsten at lodderstedt.net> wrote:
>>>>>>>
>>>>>>> jwks_uri - How is this scheme supposed to work for native clients? I
>>>>>>> assume
>>>>>>> any instance of such an application would use a distinct key pair, which
>>>>>>> is
>>>>>>> stored locally. Is the client supposed to provide a web server interface?
>>>>>>> I
>>>>>>> would rather expect this kind of client to provide the public key data
>>>>>>> directly.
>>>>> _______________________________________________
>>>>> 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
>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>
>>
>