Hi Chris, You said this subject has been touched before. Do you have a link i can read? I am NOT yet a great fan of semweb or foaf+ssl yet. (Sorry Peter Williams you haven't convinced me yet, but you are a great guy and I really miss you at the OpenID forums).
Thanks Santosh I still feel we can have a Data Model with synchronous signatures. On Fri, Dec 11, 2009 at 2:17 PM, Chris Obdam <[email protected]> wrote: > 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" <<http://[email protected]/> >> [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 < <http://[email protected]/> >> [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 < < <[email protected]> >> mailto:[email protected] <[email protected]>> >> <http://[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> >> >> <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 >> < < >> <[email protected]>mailto:[email protected]<[email protected]>> >> <http://[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> >> <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 < <<[email protected]> >> mailto:[email protected] <[email protected]>> <http://[email protected]/> >> [email protected]> wrote: >> >> >> >> On Tue, Dec 8, 2009 at 11:01 AM, John Panzer < < <[email protected]> >> mailto:[email protected] <[email protected]>> >> <http://[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 >> >> > < <[email protected]>mailto:[email protected]<[email protected]>> >> <http://[email protected]/>[email protected] / >> <<http://abstractioneer.org/> >> http://abstractioneer.org> abstractioneer.org <<http://abstractioneer.org/> >> http://abstractioneer.org> / @jpanzer >> >> > >> >> > >> >> > >> >> > On Tue, Dec 8, 2009 at 10:57 AM, Peter Watkins < < <[email protected]> >> mailto:[email protected] <[email protected]>> <http://[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 >> >> > < >> <[email protected]>mailto:[email protected]<[email protected]>> >> <http://[email protected]/>[email protected] >> >> > < <http://lists.openid.net/mailman/listinfo/openid-specs> >> http://lists.openid.net/mailman/listinfo/openid-specs> >> <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 >> >> < >> <[email protected]>mailto:[email protected]<[email protected]>> >> <http://[email protected]/>[email protected] >> >> < <http://lists.openid.net/mailman/listinfo/openid-specs> >> http://lists.openid.net/mailman/listinfo/openid-specs> >> <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> >> <http://factoryjoe.com/>http://factoryjoe.com >> > Follow me on Twitter: < <http://twitter.com/chrismessina> >> http://twitter.com/chrismessina> <http://twitter.com/chrismessina> >> http://twitter.com/chrismessina >> > >> > Citizen Agency: < <http://citizenagency.com/>http://citizenagency.com> >> <http://citizenagency.com/>http://citizenagency.com >> > Diso Project: < <http://diso-project.org/>http://diso-project.org> >> <http://diso-project.org/>http://diso-project.org >> > OpenID Foundation: < <http://openid.net/>http://openid.net> >> <http://openid.net/>http://openid.net >> > >> > This email is: [ ] shareable [X] ask first [ ] private >> > _______________________________________________ >> > specs mailing list >> > < >> <[email protected]>mailto:[email protected]<[email protected]>> >> <http://[email protected]/>[email protected] >> > < <http://lists.openid.net/mailman/listinfo/openid-specs> >> http://lists.openid.net/mailman/listinfo/openid-specs> >> <http://lists.openid.net/mailman/listinfo/openid-specs> >> http://lists.openid.net/mailman/listinfo/openid-specs >> > >> > >> > _______________________________________________ >> > specs mailing list >> > < >> <[email protected]>mailto:[email protected]<[email protected]>> >> <http://[email protected]/>[email protected] >> > < <http://lists.openid.net/mailman/listinfo/openid-specs> >> http://lists.openid.net/mailman/listinfo/openid-specs> >> <http://lists.openid.net/mailman/listinfo/openid-specs> >> http://lists.openid.net/mailman/listinfo/openid-specs >> > >> > >> _______________________________________________ >> specs mailing list >> < >> <[email protected]>mailto:[email protected]<[email protected]>> >> <http://[email protected]/>[email protected] >> < <http://lists.openid.net/mailman/listinfo/openid-specs> >> http://lists.openid.net/mailman/listinfo/openid-specs> >> <http://lists.openid.net/mailman/listinfo/openid-specs> >> http://lists.openid.net/mailman/listinfo/openid-specs >> >> >> >> >> _______________________________________________ >> specs mailing list >> <http://[email protected]/>[email protected] >> <http://lists.openid.net/mailman/listinfo/openid-specs> >> http://lists.openid.net/mailman/listinfo/openid-specs >> >> _______________________________________________ >> specs mailing list >> <http://[email protected]/>[email protected] >> <http://lists.openid.net/mailman/listinfo/openid-specs> >> http://lists.openid.net/mailman/listinfo/openid-specs >> >> >> >> ------------------------------ >> _______________________________________________ >> specs mailing list >> <http://[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 >> >> > > > -- > http://hi.im/santosh > > > _______________________________________________ > 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
