Earlier we discussed making AXSchema part of OpenID. It was on the mailinglist, finding isn't easy :-) As far as I know the discussion hasn't finished yet.
Op 11 dec 2009, om 16:00 heeft Santosh Rajan het volgende geschreven: > 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" <[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 > > > > > -- > http://hi.im/santosh > >
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
