FW: [oauth-extensions] Re: OAuth Discovery 1.0 Draft 1

["Gabe Wachob" <gabe.wachob@amsoft.net>]

Followup... Note the comments about complexity and confusion... 

-----Original Message-----
From: oauth-extensions@googlegroups.com
[mailto:oauth-extensions@googlegroups.com] On Behalf Of Eran Hammer-Lahav
Sent: Wednesday, December 12, 2007 9:29 PM
To: oauth-extensions@googlegroups.com
Subject: [oauth-extensions] Re: OAuth Discovery 1.0 Draft 1


Thanks Kevin, I was eagerly waiting for my first feedback!

Yeah, its longer than I expected too. I sat down thinking I can be done with
it in a couple of hours and ended up putting about 20 hours to get draft 1
done.

I would like to suggest breaking posts about the spec into smaller messages
so we keep track of everything. Especially in the early drafts. I'll answer
the quick questions here and others in separate posts.

---

> Regarding 5.1.1:
>
> To identify the Resource Realm, there are four options.  That seems
> like
> a lot.  Particularly as two of them involve the same HTTP header.  For
> the case of "denying Consumer access due to lack of OAuth credentials,"
> I'd like to just stick with one of the WWW-Authenticate header options.
> The response body option seems odd, because I'd only expect to need to
> parse something as an OAuth response body if I were making a request
> for
> a token.

I am ok dropping #1 and #3 but I think we need to allow a non-header option
for cases where the header is not easily accessible. I am no HTML expert and
adopted the <link> tag from suggestions made at IIW. My original idea was to
use <meta http-equiv='WWW-Authenticate'
content='realm="http://example.com/";' /> which is basically #2 in HTML.

I'll take a vote on both the number of methods, the need for an xoauth_realm
parameter, and using <link> vs <meta>.

---

> 5.3:
>
> > If a conflict exists between this specification and [XRI Resolution
> > 2.0] the definitions in this specification are to be used.
>
> That makes me wary.  If I'm trying to use existing code to parse or
> provision an XRDS document for OAuth, I'm going to need to be
> hyper-aware of what any such conflicts are, for fear of having them
> return bad results.

I plan to take this out. I also plan to take out most references to [XRI
Resolution 2.0]. I have a lot of respect for the authors of that spec but I
CANNOT make it a required reading for OAuth Discovery. I can't figure out
most of it, it is just TOO COMPLICATED. What I would like to do is simply
repeat the information needed for discovery in plain language and have
someone who is an XRI expert confirm that the discovery spec complies with
the XRI spec. As long as we don't break it, we don't need to depend on it.
The only exception is section 6 (Yadis) which is short and simple.

---

>
> 5.3.10, Parsing Process:
>
> If both a Consumer and User Realms are defined, which one do I select
> Service endpoints from?  Do I look for consumer-identity Services in
> the
> Consumer realm and in the User Realm for all others?

Yes, I added the Consumer Realm last so it is still not flowing right. User
Realms contain everything needed to obtain an Access Token. Consumer Realms
contain everything needed to obtain a Consumer Key.

---

> To what extent do you care about using this with XRI?  Closer
> examination is necessary if you're going to want to pipe all this stuff
> through standard XRI resolvers and service endpoint selection.  That
> may
> be a bit of a hypothetical at this point -- I don't know if you can
> actually install things with XML extension namespaces in the XRI global
> registry yet, and access to fully functional resolvers is still pretty
> sparse -- but as long as we are working in the XRDS framework, it's
> something to consider.  The things that raise flags for me are the
> limits on Ref-following and the need to follow Realms.

I know very little about XRI and to me the politics behind OAuth Discovery +
XRI smell a lot like OAuth Core + OpenID. My STRONG intention is to make the
discovery spec compatible/friendly to the XRI world without actually linking
the two in any way. Allow them to work together without requiring it. Sounds
familiar?

If you look at the spec, I use very little from the XRI spec:

* Yadis (section 6)
* XRDS, XRD, Query, Service, Type, URI, Expires, and the priority attribute

At this point, all of these are simple enough to just explain in the
discovery spec, keep them compliant with XRI and just mention it as a
reference people can read if they really want to.

> I haven't thought this through fully yet, but I'm tempted to drop the
> requirement to do a second round of discovery on User and Consumer
> Realms, and use XRD/Service/Ref instead, for those cases where you mean
> "this Resource Realm shares service definitions with other realms, look
> over there for the definition."

I started using <Ref> elements for both <oauth:Realm> and <oauth:Reference>.
After trying (and failing) to make sense of the XRI spec (it is really
REALLY too comlicated) I decided that I can't use a tag I can't make any
sense of. Then I looked at <Redirect> but it had some weird things. This is
why I came up with my own. If you want to try and explain to me how we can
use <Ref> in a way that will do what I describe, please educate me.

See my other post of the rest of your questions.

EHL

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"OAuth Extensions" group.
To post to this group, send email to oauth-extensions@googlegroups.com
To unsubscribe from this group, send email to
oauth-extensions-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/oauth-extensions?hl=en
-~----------~----~----~----~------~----~------~--~---