The design proposed below treats the request and response messages asymmetrically, seemingly optimized for 'RP behind firewall' ....
paul
-------- Original Message --------
| Subject: | Re: OpenID Mobile Profile? |
|---|---|
| Date: | Sat, 31 Jan 2009 17:00:19 +0900 |
| From: | Nat Sakimura <sakimura@gmail.com> |
| To: | Johannes Ernst <jernst+openid.net@netmesh.us> |
| CC: | OpenID Specs Mailing List <specs@openid.net> |
| References: | <bf26e2340901291656h4f45e5a2x3524fc1899322252@mail.gmail.com> <1CDAD9CF-3139-42EB-85B2-1DC271B76507@netmesh.us> <bf26e2340901292214r5530760ckafbbf30ce919cf7c@mail.gmail.com> <D4F759E8-C4ED-4F25-85DB-0D8E357644F5@netmesh.us> |
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@openid.net
http://openid.net/mailman/listinfo/specs
--
Nat Sakimura (=nat)
http://www.sakimura.org/en/
--
Nat Sakimura (=nat)
http://www.sakimura.org/en/
--
Paul Madsen
e:paulmadsen @ ntt-at.com
p:613-482-0432
m:613-282-8647
web:connectid.blogspot.com
Paul Madsen
e:paulmadsen @ ntt-at.com
p:613-482-0432
m:613-282-8647
web:connectid.blogspot.com