I can't say I agree about using the same format for disco as AX data.
Disco is almost certainly going to look like the Hammer stack, in
particular using web linking as the jumping off point. Neither XRD or
host-meta will be essential to this. You should be able to link an
arbitrary content type to OpenID via an HTTP Link header if you want.
If you disagree, you will find many in the RDF community who feel
similarly to you. Feel free to replace Hammer disco with POWDER,
OpenID with FOAF+SSL, and fingerpoint sounds nifty as well. Golden
hammers for everyone!
--
j
On Dec 9, 2009, at 9:35 AM, Santosh Rajan wrote:
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
_______________________________________________
specs mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-specs
