[Openid-specs-ab] Remaining Issues

hideki nara hdknr at ic-tact.co.jp
Wed Oct 13 06:36:06 UTC 2010


FB compatibility could be a good point.
But I found that  I don't like FB spec. :-)
OK, it would work anyway and I must be a matter of preference.
----
hideki

2010/10/13 Nat Sakimura <sakimura at gmail.com>:
> 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