Hi Breno, I am looking at this whole thing from a different point of view Here is how I want to explain it.
1) We need to first agree on the XML or JSON format that will be supported for discovery. It may be XRD, RDF or Atom or whatever. I am open to any format. 2) In the discovery phase only service endpoints are exposed. No other info about the user is exposed at this stage. This will presumably keep the privacy advocates happy. 2) It makes sense to use the same format, after the the authentication, for the AX phase. So if we are going to use Atom format for discovery, then let the AX phase also use Atom. That will keep the developers happy!. They need to only worry about one data format. I really want to work on this area, will anyone be interested in starting a working group on this area? If yes let us do it. Of course there are a lot of problems to be sorted on the way. But hey I think it is worth a try. Thanks Santosh On Wed, Dec 9, 2009 at 9:29 AM, Breno de Medeiros <[email protected]> wrote: > On Tue, Dec 8, 2009 at 6:56 PM, David Recordon <[email protected]> > wrote: > > Hey Nat, > > I guess I'm wondering what is missing from the PoCo schema that we've > > seen the need for within the OpenID ecosystem? It seems really rich > > already. > > PoCo is great to import information about your friends. Information > about your friends is not something that RPs want assurance about: If > you lie about your friend's birthday you get reminders at the wrong > dates. If you lie about your friend's email address, you will not be > able to share with them. > > On the other hand, if you lie about your own email address, or your > own age, it may mean you are a spammer or worse. RPs care about that. > > Giving as example the Google Accounts OP: It already supports PoCo via > OpenID+OAuth hybrid. Considering the problems we encounter with AX > long URLs, the compelling case to expose additional data via AX is not > great -- it negatively impacts the reliability of the service. > > The case to expose validation meta-data about attributes is more > interesting. Validation of significant attributes is more tightly > related to the task of authentication, so it would appear to be more > relevant to the central purpose of OpenID. It also is not available > via alternative solutions such as OAuth-protected PoCo endpoint. > > > > > I don't think that IPR is an issue around a schema, but would also be > > happy to have Facebook do an OWF agreement if it was deemed necessary. > > That said, we should focus on making sure this solves the problem of > > profile data adoption first! :) > > > > --David > > > > On Tue, Dec 8, 2009 at 5:21 PM, Nat Sakimura <[email protected]> wrote: > >> Looks nice. > >> What is the process for adding more? > >> I would like to add more like phonetic field for names and addresses. > >> (In Japanese, we call them "furigana". Without them, we do not know > >> how to read in many cases nor the sort order.) > >> Also, I feel that portablecontacts.net is a bit long... > >> Is portablecontacts only for the contact data or trying to be a general > >> schema repository like axschema? Is there any consensus in which > direction > >> we should head to? > >> What is the IPR implication? > >> =nat > >> On Wed, Dec 9, 2009 at 8:32 AM, Chris Messina <[email protected]> > >> wrote: > >>> > >>> Done. > >>> https://portablecontacts.pbworks.com/schema > >>> > >>> On Tue, Dec 8, 2009 at 1:45 PM, Joseph Smarr <[email protected]> wrote: > >>>> > >>>> Looks great to me, the only thing missing is sub-fields of complex > fields > >>>> like name, address, organization, and account. I would suggest using > another > >>>> level of slashes, e.g. > >>>> http://portablecontacts.net/ns/1.0/address/streetAddress and > >>>> http://portablecontacts.net/ns/1.0/name/familyName and so on. > >>>> > >>>> Chris-can you take a stab at adding those missing sub-fields? Then I > >>>> think we'd be good to go. > >>>> > >>>> Thanks, js > >>>> ________________________________ > >>>> From: Chris Messina [mailto:[email protected]] > >>>> Sent: Sunday, December 06, 2009 6:40 PM > >>>> To: David Recordon > >>>> Cc: SitG Admin; [email protected]; Joseph Smarr > >>>> Subject: Re: specs Digest, Vol 40, Issue 11 > >>>> > >>>> I've taken a crack at URLizing these attributes for use in Attribute > >>>> Exchange: > >>>> https://portablecontacts.pbworks.com/schema > >>>> If there are comments or feedback for improving this, let me know. I'm > an > >>>> XML noob. > >>>> Chris > >>>> > >>>> On Sun, Dec 6, 2009 at 5:05 PM, David Recordon <[email protected]> > >>>> wrote: > >>>>> > >>>>> It's missing out on the idea of having a schema which can cross > >>>>> contexts. Right now each schema – with the exception of AXSchema.org > >>>>> – has no concept of namespaces and stands alone. We've always wanted > >>>>> a schema which uses URLs to identify each element, but there haven't > >>>>> been any. Maybe Portable Contacts wants to take this on since it is > >>>>> also used by OpenSocial? > >>>>> > >>>>> --David > >>>>> > >>>>> On Sun, Dec 6, 2009 at 5:01 PM, Chris Messina < > [email protected]> > >>>>> wrote: > >>>>> > I did this in June: > >>>>> > > >>>>> > > http://spreadsheets.google.com/pub?key=pSGbbhtwI4kN_nJ1GXeQ7Qg&output=html > >>>>> > I just wish someone would actually use it! > >>>>> > Chris > >>>>> > > >>>>> > On Sun, Dec 6, 2009 at 4:02 PM, SitG Admin > >>>>> > <[email protected]> > >>>>> > wrote: > >>>>> >>> > >>>>> >>> I'm specifically pointing out that AXSchema reinvents vcard and a > >>>>> >>> host of > >>>>> >>> other profile formats, which adds yet another burden for > developers > >>>>> >>> to map > >>>>> >>> other schema, like Portable Contacts, to the AXSchema. > >>>>> >> > >>>>> >> Could these other profile formats be mapped, on an alias, to a set > of > >>>>> >> AXScheme that collectively mirror each format? As in, "vcard" > alias > >>>>> >> maps to > >>>>> >> a set of AXSchema that actually just mirror 'vcard' format. > >>>>> >> > >>>>> >> -Shade > >>>>> > > >>>>> > > >>>>> > > >>>>> > -- > >>>>> > Chris Messina > >>>>> > Open Web Advocate > >>>>> > > >>>>> > Personal: http://factoryjoe.com > >>>>> > Follow me on Twitter: http://twitter.com/chrismessina > >>>>> > > >>>>> > Citizen Agency: http://citizenagency.com > >>>>> > Diso Project: http://diso-project.org > >>>>> > OpenID Foundation: http://openid.net > >>>>> > > >>>>> > This email is: [ ] shareable [X] ask first [ ] private > >>>>> > > >>>>> > _______________________________________________ > >>>>> > specs mailing list > >>>>> > [email protected] > >>>>> > http://lists.openid.net/mailman/listinfo/openid-specs > >>>>> > > >>>>> > > >>>> > >>>> > >>>> > >>>> -- > >>>> Chris Messina > >>>> Open Web Advocate > >>>> > >>>> Personal: http://factoryjoe.com > >>>> Follow me on Twitter: http://twitter.com/chrismessina > >>>> > >>>> Citizen Agency: http://citizenagency.com > >>>> Diso Project: http://diso-project.org > >>>> OpenID Foundation: http://openid.net > >>>> > >>>> This email is: [ ] shareable [X] ask first [ ] private > >>> > >>> > >>> > >>> -- > >>> Chris Messina > >>> Open Web Advocate > >>> > >>> Personal: http://factoryjoe.com > >>> Follow me on Twitter: http://twitter.com/chrismessina > >>> > >>> Citizen Agency: http://citizenagency.com > >>> Diso Project: http://diso-project.org > >>> OpenID Foundation: http://openid.net > >>> > >>> This email is: [ ] shareable [X] ask first [ ] private > >>> > >>> _______________________________________________ > >>> specs mailing list > >>> [email protected] > >>> http://lists.openid.net/mailman/listinfo/openid-specs > >>> > >> > >> > >> > >> -- > >> Nat Sakimura (=nat) > >> http://www.sakimura.org/en/ > >> > >> _______________________________________________ > >> 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 > > > > > > -- > --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] > 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
