[Openid-specs-ab] Remaining Issues

Mike Jones Michael.Jones at microsoft.com
Wed Oct 13 15:03:02 UTC 2010


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



More information about the Openid-specs-ab mailing list