Ah, in any case I agree with the idea that AXSchema should be part of OpenID, and i will go a little further and suggest, that discovery of all URI's supported by OpenID should also be part of OpenID. :-)
I also think that is why a consistent data model is in order. On Fri, Dec 11, 2009 at 9:21 PM, Chris Obdam <[email protected]> wrote: > 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" <<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 > > > > -- http://hi.im/santosh
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
