[Openid-specs-ab] Remaining Issues

[John Bradley]

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/9fdfb681/attachment.p7s>