OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xri] XRD and JSON


right now, we're looking at formats for storing data in an XAuth payload.  Certainly, one very simple thing could be flag that states "this user has an active session at Google", and nothing more.  But you could just as easily store links to various service providers.  

So when I login to Google, it stores a small XRD in XAuth that includes a link:
  link: { rel: "photo-service", href: "http://picasaweb.google.com/" }

And then when I sign in to Yahoo, it also adds a link:
  link: { rel: "photo-service", href: "http://flickr.com/" }

And then when I go to some printing service, it can prompt me to import my photos from Flickr or Picasa.

there are huge potential privacy implications around this, so I don't know if it will even fly.  Certainly, a lot of thought has to go into exactly what data should be stored, who should have access, how access is actually controlled, etc. But conceptually, the kind of data that could be stored in XAuth is identical to what is stored in a user's XRD.  It makes a lot of sense to try and re-use XRD (or some flavor of it) rather than invent something new.  It's a small step towards a rich identity-aware user agent, but using the tools we have today.

I'm not completely clear on how the access controls work, either for reading or writing data, but what I've heard has lead me to believe that the data does not necessarily need to be signed.

-will

On Thu, Apr 22, 2010 at 3:20 PM, John Bradley <jbradley@mac.com> wrote:
Can you explain the initial use case a bit for us?

John B.

On 2010-04-22, at 5:45 PM, Will Norris wrote:

you either have:
  1) a no-brainer method of switching between XML and JSON like JsonML, and then have to do some work to get the JSON into the right logical object, or
  2) a no-brainer JSON format that can be used as-is, and you have to do a little work to switch between the XML and JSON formats

It's just a matter of which one you want to optimize for.

Signatures are of course an issue, and I don't really have an answer for that.  The immediate use-case we're looking at wouldn't necessarily need signatures, though.

-will


On Thu, Apr 22, 2010 at 1:25 PM, John Bradley <jbradley@mac.com> wrote:
I am still trying to understand the use case.

Having multiple discovery formats each requiring separate processing is not optimal.

Being able to transform from one to the other may have advantages.

I am speculating that the Google wants a discovery format that can be entirely parsed with JS inside the browser.

I am not personally religious about XML. 

If a JSON  format that can be transformed into the equivalent XML XRD can be specified that may be a useful work product for the TC.

My main concerns are around signatures if this starts being used on the server as well as in the browser.

The Google seems to have decided this week that going outside the existing standards development process is more efficient.
I would prefer that this not result in competing discovery standards.

It is worth discussing, but at the end of the day Google may need to do what it needs to do.

John B.

On 2010-04-22, at 3:04 PM, Will Norris wrote:

On Thu, Apr 22, 2010 at 10:58 AM, Scott Cantor <cantor.2@osu.edu> wrote:
> JsonML does a far better job than some other similar utilities I've seen,
so
> that is certainly nice.  And for it's stated goals of providing a compact
> format for transporting XML, it works great.  But that kind of misses the
> point of using JSON, which is to provide an natural representation of the
> object, not just a document.

I think the document is the natural representation. A simple layer of code
addresses whatever limitations might exist in the language that's purporting
to be too difficult to use the document in.

But as a matter of specification, the problem you have is that, like SAML,
there's an explicit characterization of the notion of an XRD as being XML.
If it's not XML, it's not an XRD. I have not seen a simple way around that.

A separate specification can be created to establish an interchange format
in some other encoding with a different label attached to it, but if the
goal here was to allow for non-XML representations of an XRD, it would
require some fairly big changes that I'm pretty comfortable saying nobody
wants to take on.

certainly, I wasn't meaning to suggest a departure of any kind from how XRD is defined today.  I've been quite upfront from the beginning of my involvement with this TC that I view XRD (as it's specified) solely as an XML format, and if you want something else, then do it yourself.  Well, now Google is sort of doing it ourselves, and we figured that if others end up wanting to do the same, it might be good to have agreement on what that JSON format looks like.  That could just be a whitepaper, a best practice guide, or whatever.  It certainly doesn't have to be a product of this TC, I just thought I would see if it was anything folks had any interest in it.

-will






[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]