[Openid-specs-ab] Remaining Issues

John Bradley jbradley at mac.com
Tue Oct 12 19:57:46 UTC 2010


Yes in principal it also supports the delegation scenario.  The protocol for that would need to support the proxy sending its sig_params to the first signer for inclusion in the signed object for that to work.    It is a bit more complicated example.

That is the downside of including the sig_params in the signed info.

This may be a question for Tony.

Since we are not supporting signing Reference, where it is important to have the DigestMethod signed to prevent substitution,

In our case could the signature algorithm and hash method be outside the SignedInfo?

That would make the delegation case much simpler.

Altering the DigestMethod just causes the signature to not validate 

I really don't like the idea of inserting elements into the payload.   

So the question is if we don't support Reference is there anything other than the payload that needs to be signed?

John B.
On 2010-10-12, at 2:27 PM, Mike Jones wrote:

> What you wrote below makes sense.  Talking with Tony, he also pointed out that multiple signatures are common in delegation scenarios, so as to establish a chain of authority.
> 
> 				-- Mike
> 
> -----Original Message-----
> From: John Bradley [mailto:jbradley at mac.com] 
> Sent: Tuesday, October 12, 2010 9:44 AM
> To: Mike Jones
> Cc: Nat Sakimura; openid-specs-ab at lists.openid.net
> Subject: Re: [Openid-specs-ab] Remaining Issues
> 
> It is not uncommon to have multiple signatories to a document.   It is supported by xmldsig.
> 
> For something like contract exchange where you have two parties signing a document it would be useful.
> 
> It's true that having multiple signatures is uncommon in the authN case, however we were trying to make this a generally applicable signing method.
> 
> It is true that you could wrap the signed document A inside of another signature envelope B to get a similar effect.
> 
> There is also the use case where for authN the issuer may use a high and low security signature for backwards compatibility,  perhaps HMAC-SHA256 RSA-256 and ECDSA-SHA512.
> 
> It is a trade off between simplicity and general functionality, as I see it.
> 
> John B.
> 
> 
> 
> On 2010-10-12, at 1:24 PM, Mike Jones wrote:
> 
>> Nat, what is it about your use case that motivates multiple signatures?
>> 
>> 				-- Mike
>> 
>> -----Original Message-----
>> From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Anthony Nadalin
>> Sent: Tuesday, October 12, 2010 9:03 AM
>> To: Nat Sakimura; openid-specs-ab at lists.openid.net
>> Subject: Re: [Openid-specs-ab] Remaining Issues
>> 
>> 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 
>> 
>> I would like to see a payload, this would also allow for encryption
>> 
>> -----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
>> 
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>> 
>> _______________________________________________
>> 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/bbda467f/attachment.bin>


More information about the Openid-specs-ab mailing list