How do other people feel about making axschema part of AX/OpenID? Op 11 dec 2009, om 17:42 heeft Santosh Rajan het volgende geschreven:
> 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" <[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 >> >> > > > > > -- > http://hi.im/santosh > >
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
