[Openid-specs-ab] Developer Feedback

Nat Sakimura sakimura at gmail.com
Mon Jul 11 17:16:11 UTC 2011

Dear Connectors:

I went to "Identity Conference #9" held at mixi in Tokyo Friday.
The event attracted about 70 (mostly) developers.

One of the session was talking about OpenID Connect. (I did not plan it, by
the way. It was voluntarily done.)
I was amazed by the fact that the speaker was using the Thursday's version
of the spec to explain it.

Several Findings:

1. We should make sure to place HTTP Redirect Binding as the Center Piece.
   This actually is the confusion that even Breno was falling into. He was
thinking that Core was something to be implemented.
   It is not. It is the HTTP Redirect Binding that the developers should
read. We may want to rename it to something more
   attractive and feel as the main spec. (Perhaps rename core as "Messages"
and let the HTTP Binding assume the name
   "Core" etc.?)

2. Short names are unpopular.
    Perhaps because it was mainly the web falks at the conference, but the
short names like "mxa" are extremely unpopular.
    They were saying that they were not intuitive, ugly, etc. and it will
increase the support cost for the IdP.
    This is consistent with Facebook's feedback. It's kind of too late in
the game but we may want to do something to
    change that perception at least. (My 2c: use long_name instead.)

Wrt 2. above, I have done some analysis on the impact if we change the short
names to long_names.

JWT and OpenID Connect claims, though have some overlaps, serves two
distinct purposes.
While JWT is to serialize JSON into a string with smallest possible overhead
(hence short names),
OpenID Connect claims are standardized claims for JSON, so the length tends
to be less of an issue.

If short names have value, then it probably would be on some feature phones
with limited URL length.
Let us see the impact of the short and long names on feature phones.

First of all, let us see which flow feature phones are likely to use:
Since most feature phones do not have Javascript, it is unlikely that they
are going to use UserAgent flow.
Thus what we are left with are "code" flow.

To see the impact of the longer claim names, we need to examine both request
and response as well as the use of the response subsequently.

(1) Request

To send the request parameters, it has two choices. a) Request Parameters b)
Request File URL.

Since feature phones can always use b), request object size seems to be less
of an issue.

If one wants a), we have to consider the following:

(i) OAuth Parameters: Example in OAuth draft 16 has 116 bytes, so we are
left with 396 bytes.
(ii) RSA 2048 Sig string is 343 bytes. HMAC-SHA256 is 44 bytes, as I
     So, 53 bytes for RSA left, and 352 bytes for HMAC. At this point, we
have to give up RSA.
(iii) Header length for JWT Example is 41 chars. So, for HS256, we have 311
(iv) The example request after adding "fmt":"sig", is 338 bytes, so it does
not fit anyways.
      On the other hand, if we delete all the "clm" keys in the userinfo
      we will get 193 and 293 bytes respectively. Either does fit.

Thus, longer name seem to be ok.

(2) Response

Response that goes through browser only contains "code" and "state", so long
name should not matter.

(3) Subsequent Use

If id_token is handed to the browser as "cookie" for session management,
we should consider the length limitation.
However, many of the feature phones actually do not even support cookies.
(NTT docomo phones till recently did not support cookies.)
Besides, id_token is using long names to start with.

Thus, long_names seem to be ok.

Then, what would be the long names would be?

Here are my suggestions:

inf -> userinfo****

idt -> id_token****

clm -> claims****

fmt -> format****

mxa -> max_age****

eaa -> iso29115****

nor -> unsigned****

sig -> signed****

enc -> encrypted****

aat -> auth_time

loc -> locale
opt -> optional

What would you think?

Perhaps this can be one of the topic of today's call.

Nat Sakimura (=nat)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110712/ce815ab1/attachment.html>

More information about the Openid-specs-ab mailing list