[Openid-specs-ab] Remaining Issues

John Bradley jbradley at mac.com
Wed Oct 13 00:26:54 UTC 2010


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

-------------- 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/20101012/51b7f9bd/attachment.bin>


More information about the Openid-specs-ab mailing list