[Openid-specs-ab] Remaining Issues

Anthony Nadalin 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

-----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

More information about the Openid-specs-ab mailing list