[Openid-specs-ab] Remaining Issues
tonynad at microsoft.com
Tue Oct 12 16:02:56 UTC 2010
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
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"
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
More information about the Openid-specs-ab