This is a subject which has been touched before. First question is: should OpenID incorporate a datamodel.
Yes, I think. RP need more clearity on this matter. Op 10 dec 2009, om 16:37 heeft Santosh Rajan het volgende geschreven: > > As usual I am going to digress a bit here. As far as I can see, the problem > with OpenID is that it does NOT have a "data model". > > When we look at a data model, we don't really need to worry about the > serialization format. It could be anything, POST message key values, JSON, > RDF or Atom. The important thing is that we need a data model, and a > consistent one at that, through out the OpenID protocol process. > > Once we have a proper data model in place, answering all these "discovery" > and "AX" questions will be trivial. > > One more point about the trust issue. I am all for synchronous signatures > rather than asynchronous. > > I am working on this. But this is not something I can do alone. Any > collaboration will be appreciated. And all work will be done under the OpenID > IPR. > > Thanks all, > Santosh > > > 2009/12/10 Nat <[email protected]> > This is a CX use case. In CX, user consent is captured in a signed document > called contract together with what gets sent under what circumstances. The > contract gets a unique URL to identity it and one can use that to point to > the collection of data as well. > > The WG is up and running so there is no need to wait. > > =...@tokyo via iPhone > > On 2009/12/10, at 12:19, Allen Tom <[email protected]> wrote: > >> Automatically sharing profile/avatar pic (with user consent) definitely adds >> a lot of value to both users and RPs, and profile pic was one of the most >> frequently requested attributes that we heard from potential RPs. >> >> The Yahoo OP currently shares the URL to the user’s Yahoo Profile pic, >> however, the pic does not automatically get updated when the user updates >> their Yahoo Profile pic. >> >> One of the things that I’d like to clarify in AX 1.1 is whether or not RPs >> should be able to deep link directly to the profile pic, or if they’re >> expected to download and cache it themselves. Also, if RPs are able to deep >> link to the profile pic, then we should also define whether or not the >> content of the URL be updated when the user updates their pic. >> >> Allen >> >> On 12/9/09 5:17 AM, "Jonathan Coffman" <[email protected]> wrote: >> >> Avatars would definitely be huge. I can't tell you how frustrating it is as >> a user to update my avatar on all of the hundreds of sites I may encounter >> that require login. >> >> Professionally, I've run into problems when bringing up Gravatar as a >> potential option... but again, that sets the bar so high that users are >> pretty unlikely to even go through that process. >> >> Jonathan >> >> >> On Dec 9, 2009, at 2:09 AM, Chris Messina wrote: >> >> +1. I think those are the basic profile building blocks for social software. >> The avatar is something we particularly need for openid. >> >> Sent from my iPhone 2G >> >> On Dec 8, 2009, at 22:06, John Panzer <[email protected]> wrote: >> >> For my use cases, the important things are, unscientifically, >> >> 1. Display name >> 2. Avatar / photo >> 3. Preferred link to human-readable online presence -- profile, blog, >> whatever strikes their fancy. >> >> >> >> >> On Tue, Dec 8, 2009 at 8:38 PM, David Recordon < >> <mailto:[email protected]> [email protected]> wrote: >> I'm sure that the data is wildly out of date, but at the time the SREG >> fields ( >> <http://openid.net/specs/openid-simple-registration-extension-1_0.html#response_format> >> >> http://openid.net/specs/openid-simple-registration-extension-1_0.html#response_format) >> were based on looking at what a few hundred different sites were >> asking for. >> >> I unscientifically think that the extremely common stuff is: >> - Name >> - Avatar / photo >> - Email address >> >> Scientifically, we should actually put some effort into looking at >> sign in pages again. :) >> >> --David >> >> >> On Tue, Dec 8, 2009 at 7:59 PM, Jonathan Coffman >> < <mailto:[email protected]> [email protected]> wrote: >> > Out of curiosity, beyond the email discussion below what are the primary >> > metadata needs around the other major (PoCo) fields? >> > Speaking to the use-cases I work off of here at PBS, I'm primarily >> concerned >> > about emails being verified (and a signup date is also useful) and am most >> > inclined to trust the OP (especially if it were a white-listed or >> otherwise >> > vetted iDP). >> > Jonathan >> > >> > On Dec 8, 2009, at 2:17 PM, Chris Messina wrote: >> > >> > Is it worth looking at how Facebook handles the passing of profile data? >> Or >> > is their architecture/use case different? >> > >> > <http://wiki.developers.facebook.com/index.php/Users.getInfo> >> http://wiki.developers.facebook.com/index.php/Users.getInfo >> > On Tue, Dec 8, 2009 at 11:08 AM, Breno de Medeiros < >> <mailto:[email protected]> [email protected]> wrote: >> >> >> >> On Tue, Dec 8, 2009 at 11:01 AM, John Panzer < >> <mailto:[email protected]> [email protected]> wrote: >> >> > For "one-time" URLs, you'd probably want to allow for retries for a >> >> > short >> >> > period (or just allow it to be accessed for say 5m) which would have >> >> > approximately the same level of protection. >> >> > You could also imagine long-lived capabilities along the lines of OAuth >> >> > tokens that allow RPs to repeatedly refresh the data as needed. >> (Better >> >> > of >> >> > course if they can subscribe to changes, but that's an implementation >> >> > detail >> >> > and definitely a separate spec.) >> >> > Given that AX already supports requesting URL-valued data (e.g., >> profile >> >> > photos) I think this just comes down to defining a fairly complicated >> >> > data >> >> > type for AX and passing a URL around. >> >> >> >> A more lightweight alternative is to adopt an 'artifact' mode where >> >> most of the OpenID assertion (request and response) can be passed in >> >> the backchannel. That is a bit more difficult to implement but easier >> >> to spec (because the existing URLs can be used) and more general >> >> (compacts all extensions, not only AX). >> >> >> >> > -- >> >> > John Panzer / Google >> >> > <mailto:[email protected]> [email protected] / >> <http://abstractioneer.org> abstractioneer.org <http://abstractioneer.org> >> / @jpanzer >> >> > >> >> > >> >> > >> >> > On Tue, Dec 8, 2009 at 10:57 AM, Peter Watkins < >> <mailto:[email protected]> [email protected]> wrote: >> >> >> >> >> >> On Tue, Dec 08, 2009 at 10:32:12AM -0800, John Panzer wrote: >> >> >> >> >> >> > provide to RPs. If you send an endpoint URL to the RP instead of >> the >> >> >> > information itself, the RP can then retrieve it via a backchannel >> >> >> > (and >> >> >> > cache >> >> >> > it). If you have private data, use a capability URL with a token >> >> >> > that >> >> >> > allows read-only access. >> >> >> >> >> >> Exactly. OpenID requests and responses are very chatty, and >> backchannel >> >> >> URLs could be an easy way to get around the 2k GET limit (the cost of >> >> >> course being additional time needed to make the additional HTTP >> >> >> requests). >> >> >> >> >> >> I don't see any reason for backchannel URLs to be requested multiple >> >> >> times, >> >> >> so in addition to a request or response using strongly random nonces >> in >> >> >> the backchannel URLs, the backchannel URLs should be very short-lived, >> >> >> probably each side "SHOULD" allow a URL to be requested only once, and >> >> >> throw a 403/404 for subsequent requests. >> >> >> >> >> >> Is there any draft of AX using backchannel URLs? >> >> >> >> >> >> -Peter >> >> > >> >> > >> >> > _______________________________________________ >> >> > specs mailing list >> >> > <mailto:[email protected]> [email protected] >> >> > <http://lists.openid.net/mailman/listinfo/openid-specs> >> http://lists.openid.net/mailman/listinfo/openid-specs >> >> > >> >> > >> >> >> >> >> >> >> >> -- >> >> --Breno >> >> >> >> +1 (650) 214-1007 desk >> >> +1 (408) 212-0135 (Grand Central) >> >> MTV-41-3 : 383-A >> >> PST (GMT-8) / PDT(GMT-7) >> >> _______________________________________________ >> >> specs mailing list >> >> <mailto:[email protected]> [email protected] >> >> <http://lists.openid.net/mailman/listinfo/openid-specs> >> http://lists.openid.net/mailman/listinfo/openid-specs >> > >> > >> > >> > -- >> > Chris Messina >> > Open Web Advocate >> > >> > Personal: <http://factoryjoe.com> http://factoryjoe.com >> > Follow me on Twitter: <http://twitter.com/chrismessina> >> http://twitter.com/chrismessina >> > >> > Citizen Agency: <http://citizenagency.com> http://citizenagency.com >> > Diso Project: <http://diso-project.org> http://diso-project.org >> > OpenID Foundation: <http://openid.net> http://openid.net >> > >> > This email is: [ ] shareable [X] ask first [ ] private >> > _______________________________________________ >> > specs mailing list >> > <mailto:[email protected]> [email protected] >> > <http://lists.openid.net/mailman/listinfo/openid-specs> >> http://lists.openid.net/mailman/listinfo/openid-specs >> > >> > >> > _______________________________________________ >> > specs mailing list >> > <mailto:[email protected]> [email protected] >> > <http://lists.openid.net/mailman/listinfo/openid-specs> >> http://lists.openid.net/mailman/listinfo/openid-specs >> > >> > >> _______________________________________________ >> specs mailing list >> <mailto:[email protected]> [email protected] >> <http://lists.openid.net/mailman/listinfo/openid-specs> >> http://lists.openid.net/mailman/listinfo/openid-specs >> >> >> >> _______________________________________________ >> specs mailing list >> [email protected] >> http://lists.openid.net/mailman/listinfo/openid-specs >> _______________________________________________ >> specs mailing list >> [email protected] >> http://lists.openid.net/mailman/listinfo/openid-specs >> >> >> _______________________________________________ >> specs mailing list >> [email protected] >> http://lists.openid.net/mailman/listinfo/openid-specs >> _______________________________________________ >> specs mailing list >> [email protected] >> http://lists.openid.net/mailman/listinfo/openid-specs > > _______________________________________________ > specs mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-specs > > > > > -- > http://hi.im/santosh > > > _______________________________________________ > specs mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-specs
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
