--- On Wed, 12/29/10, Marius Scurtescu <mscurte...@google.com> 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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
