[Openid-specs-ab] Remaining Issues

John Bradley jbradley at mac.com
Wed Oct 13 16:05:33 UTC 2010 

I think that it should be recommended that the token contain a link to the public key or a thumbprint,  but not required.

I am just agreeing with Mike that making the fields required may be overkill.

John B.
On 2010-10-13, at 12:38 PM, Anthony Nadalin wrote:

> So I think that the key advertisement can be done several ways but I think that the simplest way would be to use the JSON token as a way to get/discover keys
> 
> -----Original Message-----
> From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of John Bradley
> Sent: Wednesday, October 13, 2010 8:07 AM
> To: Mike Jones
> Cc: openid-specs-ab at lists.openid.net
> Subject: Re: [Openid-specs-ab] Remaining Issues
> 
> OK I will rework that part unless there are objections.
> 
> John B.
> On 2010-10-13, at 12:03 PM, Mike Jones wrote:
> 
>> I'd rather it be RECOMMENDED, as (per our phone call), there are other potential means for advertising/discovering/obtaining public keys that could be used than placing them in an X.509 cert at a URL.  I think the signing spec will be more general if we don't completely tightly bind the JSON signing spec to a particular key discovery mechanism.
>> 
>> 				-- Mike
>> 
>> -----Original Message-----
>> From: openid-specs-ab-bounces at lists.openid.net 
>> [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of John 
>> Bradley
>> Sent: Wednesday, October 13, 2010 5:09 AM
>> To: Nat Sakimura
>> Cc: openid-specs-ab at lists.openid.net
>> Subject: Re: [Openid-specs-ab] Remaining Issues
>> 
>> In  2. Signature paramaters we made key_id optional so that in the simple case where the default is HMAC-SHA256 we can drop the Signature parameters completely to be compatible with the current FB format.
>> 
>> certs_uri is still required for RSA-SHA256.
>> 
>> If it is required it should probably be required for all asymmetric signatures.
>> I can imagine that there may be cases where there might only be one key pair being used and it might not be required.
>> 
>> Thoughts on making the element RECOMMENDED for all asymmetric signatures rather than required?
>> 
>> John B.
>> On 2010-10-13, at 12:19 AM, Nat Sakimura wrote:
>> 
>>> Just for the sake of discussion I have updated 
>>> http://jsonenc.info/jss/1.0/ to reflect the talk that I had with John 
>>> this morning. It is now compatible with Facebook implementation and 
>>> hopefully more or less in-line with JSON Web Token proposal which is 
>>> being prepared by Mike et. al. as well.
>>> 
>>> Let us see if we can converge.
>>> 
>>> =nat
>>> 
>>> On Wed, Oct 13, 2010 at 9:26 AM, John Bradley <jbradley at mac.com> wrote:
>>>> If we were to unify the envelope then we would need to be clear on the order of precedence.
>>>> 
>>>> The other issue is that the signature info winds up not being encrypted.
>>>> 
>>>> I like the existing compose-ability of having a payload that can cleanly contain the other.
>>>> 
>>>> The envelopes can be the same but I wouldn't want to do both signing and encryption at the same time.
>>>> 
>>>> John B.
>>>> On 2010-10-12, at 8:55 PM, Nat Sakimura wrote:
>>>> 
>>>>> On Wed, Oct 13, 2010 at 1:02 AM, Anthony Nadalin <tonynad at microsoft.com> wrote:
>>>>>> I'm OK with either short or long names
>>>>>> 
>>>>>> I really believe that we need sig_parms and if the receiver 
>>>>>> supports the algorithm but does not support all the sig_parms the 
>>>>>> token may be rejected, it would be nice to have a set of agreed 
>>>>>> base sig_parms for each algorithm as some algorithms have many 
>>>>>> parms
>>>>>> 
>>>>> 
>>>>> That would be a good idea. Do you have specific proposals?
>>>>> 
>>>>>> I would like to see a payload, this would also allow for 
>>>>>> encryption
>>>>> 
>>>>> Yes. Currently we have different envelopes for Signature 
>>>>> (http://jsonenc.info/jss/1.0/ OR 
>>>>> http://jsonenc.dinfo/jss/1.0/json-simple-sign-1_0a.html ) and 
>>>>> Encryption (http://jsonenc.info/enc/1.0 ). If we have "payload" and 
>>>>> "sig_params", we can unify the envelope. (JSON Encryption was 
>>>>> written before Signature got sig_params and payload so it is taking 
>>>>> the current form.)
>>>>> 
>>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: openid-specs-ab-bounces at lists.openid.net
>>>>>> [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Nat 
>>>>>> Sakimura
>>>>>> Sent: Tuesday, October 12, 2010 2:27 AM
>>>>>> To: openid-specs-ab at lists.openid.net
>>>>>> Subject: [Openid-specs-ab] Remaining Issues
>>>>>> 
>>>>>> So far, the feedbacks that I got are:
>>>>>> 
>>>>>> For the main spec:
>>>>>> 
>>>>>> * Make 8.3 and 8.4 optional so that there could be two leg style request  -> I am not sure if this should be in AB as there is no "artifact"
>>>>>> involved then.
>>>>>>   Perhaps it is better to save it for Connect or CX?
>>>>>> 
>>>>>> * _url and _uri are mixed. Understand that the authors made 
>>>>>> careful selection of the terms, but it may be too much. Better standardize on _uri  -> OK to standardize on _uri ?
>>>>>> 
>>>>>> For the signature spec (JSS):
>>>>>> 
>>>>>> * Try to Unify with JWT for the Web Token serialization and signature:
>>>>>> -> As I understand, the main deltas are:
>>>>>> * Whether to use short names as in JWT or long name as in Facebook.
>>>>>> * Whether to have sig_params so that it can support multiple signers and keys.
>>>>>> * Whether to have "payload" or just inserting signature parameters to the original JSON Object.
>>>>>> 
>>>>>> For JSON serialization of JSS:
>>>>>> 
>>>>>> * Whether to use "dictionary" as in the current proposal or "array"
>>>>>> which simplifies bunch of things.
>>>>>> 
>>>>>> For JWT serialization:
>>>>>> 
>>>>>> * Whether to allow multiple signatures by sig1.sig2.sig3. ... . payload style.
>>>>>> 
>>>>>> Please indicate your preferences.
>>>>>> 
>>>>>> --
>>>>>> Nat Sakimura (=nat)
>>>>>> http://www.sakimura.org/en/
>>>>>> http://twitter.com/_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)
>>>>> http://www.sakimura.org/en/
>>>>> http://twitter.com/_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)
>>> http://www.sakimura.org/en/
>>> http://twitter.com/_nat_en
>>> _______________________________________________
>>> 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: 4767 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20101013/61492757/attachment.p7s>

More information about the Openid-specs-ab mailing list