Subject: Re: [OAUTH-WG] unregistered applications

From: Francisco Corella <[email-masked]>
Date: Mon, 3 Jan 2011 08:21:17 -0800 (PST)

--- On Wed, 12/29/10, Marius Scurtescu <[email-masked]> wrote:
...
> I don't think it adds much complexity. And for implementors it is a
> big help, much simpler to implement /.well-known/host-meta. Imagine
> asking a large website to add a few HTML tags to every single request
> to / as opposed to adding a special file.

OK, but there is another problem: /.well-known/host-meta
will usually be an http URI, and I need an https URI.
On the other hand, I can use a well-known URI such as 
/.well-known/pkauth.  That's what I'm saying now in a 
new revision of the paper.

...
> > First, in OAuth the client is also a Web application, isn't
> >
 it?  What else could it be?
>
> A native app, a JavaScript widget, a device.

> https://datatracker.ietf.org/doc/draft-zeltsan-use-cases-oauth/

Ah, OK.  I can see why those use cases are important, so
I've been working to accommodate them over the last few days.
The result is very nice :-).  I can handle those clients without 
profiling.  That is, the PKAuth server does not need to know 
whether it is talking to a traditional Web application, a native app, 
a browser-resident application such as a Javascript widget, or
an "autonomous client".  I've incorporated this into the 
new revision.

> > exchange provides no security.  In PKAuth there is only one
> > token, which is sent to the direct callback endpoint and
> > does not run the risk of falling into the wrong hands.  I've
> > added this argument to the paper.
>
> I
 think you still have two tokens, the reference code (similar to the
> authorization code in OAuth 2) and an authorization token (access /
> refresh token in OAuth 2).

You were right about this, but now, as a result of the
changes I had to make to accommodate different kinds of
clients, there is only one token.

Francisco