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

[John Bradley]

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
>> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4507 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131115/f7c49753/attachment.p7s>