[Openid-specs-ab] Standardize on Magic Signature format for everything?

[Nat Sakimura]

I just hate association and normalization. It was the worst part of
the OpenID Authn 2.0.

Even if we were to do association, I am not sure why cannot I just
send a secret string to the OAuth Authz Server
instead of HMAC. That will remove all the "normalization" pain.

So -100 for HMAC. It adds nothing over the password, and adds tons of
complexity if we are to do it over SSL.

Using Magic Signature is a win because we do not need to maintain association.
What about having "sig" parameter hold b64 magic signature?

On Thu, May 27, 2010 at 10:10 AM, John Bradley <jbradley at mac.com> wrote:
> If we want to be compatible with connect we need to drop magic signature as a wrapper.
>
> We include the client secret in the request.
>
> Connect uses a  hmac-sha256 signature over the key-value elements including the access token with the shared secret.
> I don't think that adds anything other than complexity for the web-server flow.
>
> If a asymmetric signature is required we are better off adding a magic signature as an additional element.
>
> That way the response can be compatible with connect.
>
> That however gets us back to needing associations to get the client_id == association_handle and secret == mac_key.
>
> John B.
>
>
> On 2010-05-26, at 11:03 AM, Nat Sakimura wrote:
>
>> Yesterday, I had a talk with John B. that it might be better to use
>> Magic Signature Envelope all the time whether we sign or not.
>>
>> Right now, our request and response when not signed looks like this:
>>
>> {
>>    "ns":"http://specs.openid.net/auth/2.0",
>>    "mode":"direct_checkid_setup",
>>    "redirect_url":"https://example.com/rp/endpoint_url"
>>    "ns.ax":"http://openid.net/srv/ax/1.0"
>>    "ax.mode":"fetch_request"
>>    "ax.type.fname":"http://example.com/schema/fullname"
>>    "ax.type.gender":"http://example.com/schema/gender"
>>    "ax.required":"fname,gender"
>>    "ax.update_url":"http://idconsumer.com/update?transaction_id=a6b5c4"
>> }
>>
>> If we encapsulate it in Magic Envelope, it will be like
>>
>> {
>>  "data_type":"application/json",
>>  "encoding":"base64url",
>>  "alg":"NONE"
>>  "data":"base64url_encoded data",
>>  "plain":
>>    {
>>    "ns":"http://specs.openid.net/auth/2.0",
>>    "mode":"direct_checkid_setup",
>>    "redirect_url":"https://example.com/rp/endpoint_url",
>>    "ns.ax":"http://openid.net/srv/ax/1.0",
>>    "ax.mode":"fetch_request",
>>    "ax.type.fname":"http://example.com/schema/fullname",
>>    "ax.type.gender":"http://example.com/schema/gender",
>>    "ax.required":"fname,gender",
>>    "ax.update_url":"http://idconsumer.com/update?transaction_id=a6b5c4"
>>     }
>>  "sigs": [
>>    {
>>    "value": "",
>>    "keyhash": ""
>>    }
>>  ]
>> }
>>
>> While this certainly is a possibility and gives us more consistent and
>> uniform request/response format,
>> I think it is too busy for no-sign case. Also, it will be less
>> compatible with "Connect" etc.
>> What do you guys think?
>>
>> --
>> 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
>
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en