OpenID Mobile Profile?

[Nat Sakimura]

:-)

So we shall contiue. =zigorou, who wrote the Japanese presentation that Wil
translated also posted a message to this list, but it apparently has gone
into a moderation queue for some reason... So, here is his text:

--------
Hi.

I'm Toru Yamaguchi (=zigorou).
I'm interested in OpenID for Mobile.

My presentation of OpenID for Mobile(Jp) was translated by wil(=wil).
http://dready.org/blog/2009/01/02/mobile-openid-in-japan/

----------

Now, as to the mobile/artifact mode, I kind of feel that it probably is
better to establish a second channel.

So, the flow is like:

1. RP constract a request string as usual (including ones for the various
extensions -- means it could be fairly long.)
2. RP posts this to the OP's artifact mode endpoint published in OP's XRD.
3. OP issues a nonce as an "artifact" or "ticket".
4. RP redirects the browser with this artifact.
5. OP, receiving this artifact, reconstructs the OpenID message from the
    post received in step 2 above.
6. Credentail presentation etc. happens as usual, and OP verifies the user's
identity.
7. OP creates a positive response and stores it with the artifact as the
key.
8. OP redirects the browser with the artifact to the RP.
9. RP fetches the response created in 7. and examines it to authorize the
access.

Nice thing about this is that it probalby is going to be a very little code
addition to the current libraries.

The difference between this flow and the SAML artifact binding is that in
case of SAML, the artifact/ticket is created by the RP and OP goes and fetch
the request from RP. I chose this design because RP can be inside the
firewall when OP is on the internet which is a more likely use case  for
OpenID.

=nat

On Sat, Jan 31, 2009 at 3:21 AM, Johannes Ernst <jernst+openid.net@
netmesh.us> wrote:

> In which case, back to your original question:
>
> Are there poeple who are interested in discussing OpenID Mobile profile
> sort of thing?
>
>
> My answer would be "Yes".
>
>
>
> On Jan 29, 2009, at 22:14, Nat Sakimura wrote:
>
> There are two issues involved.
>
> 1) URL length etc. limitations
> 2) User interface
>
> 1) has impact on 2).
>
> For instance, we want to avoid the users pressing buttons when redirecting.
>
> And, in many cases, we do not have javascript.
> This means we are left with GET and this URL length limitation becomes an
> issue.
>
> 2) cannot be solved globally because it could very well be somewhat
> dependent on
> the carrier implementation and handset capability.
> For most of the phones in Japan, we can get unique
> id for each handset at http level fairly securely so we can depend on it to
>
> avoid any typing (not even username etc.). This was one of the factor why
> m-commerce got so popular in Japan.
>
> In many other markets, e.g., the U.S., this is not granted. Thus, some
> other means
> are required. I know, WIl Tan of Maleysia is working something on iPhone in
> this regard.
> Essentially, it needs to be solved per carrier or per handset class
> (e.g., mid-p enabled phones, etc.), I think.
>
> =nat
>
> On Fri, Jan 30, 2009 at 2:56 PM, Johannes Ernst <jernst+openid.net@
> netmesh.us> wrote:
>
>> Are you talking about URL length limitations for the identifiers that
>> users need to enter, or for URLs that are being sent around as part of the
>> protocol?
>> IMHO the most important question to ask for mobile devices is: can we do
>> without "typing" anything?
>>
>> On Jan 29, 2009, at 16:56, Nat Sakimura wrote:
>>
>> Hi.
>>
>> Are there poeple who are interested in discussing OpenID Mobile profile
>> sort of thing?
>> Mobile phones has unique challenges of being restricted in URL length etc.
>>
>> OpenID as it stands now has very lengthy URLs in both requests and
>> responses and it sometimes does not fit into the restrictions.
>> SAML world has defined artifact binding to cope with it. IMHO, OpenID
>> should define something like that also.
>>
>> In Japan, there are bunch of people (including mobile carriers) who wants
>> to do it.
>>
>> Are there interest here as well?
>>
>> --
>> Nat Sakimura (=nat)
>> http://www.sakimura.org/en/
>>  _______________________________________________
>> specs mailing list
>> specs at openid.net
>> http://openid.net/mailman/listinfo/specs
>>
>>
>>
>
>
> --
> Nat Sakimura (=nat)
> http://www.sakimura.org/en/
>
>
>


-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20090131/b0e0b7a8/attachment-0001.htm>