[Openid-specs-ab] Remaining Issues
tonynad at microsoft.com
Wed Oct 13 15:40:25 UTC 2010
> The envelopes can be the same but I wouldn't want to do both signing and encryption at the same time
Not sure I follow, are you saying that you would not want to sign then encrypt or encrypt and then sign?
From: John Bradley [mailto:jbradley at mac.com]
Sent: Tuesday, October 12, 2010 5:27 PM
To: Nat Sakimura
Cc: Anthony Nadalin; openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] Remaining Issues
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.
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)
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
> Nat Sakimura (=nat)
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
More information about the Openid-specs-ab