Re: [apps-discuss] [http-auth] Web Keys and HTTP Signatures

[Michael Thomas <[e-mail]>]

Manu Sporny wrote:

> The Javascript implementation of HOBA is also
> a hack in that it shoves authentication parameters into the URL and we
> /definitely/ don't want a Web where that becomes the norm. If this stuff
> is going to be integrated into the browser, we should not create a
> solution that makes it difficult for that to happen.

Um, HOBA-js is just client server protocol. It is completely normal and expected
for a web site to define the url parameters coming from the client. There's nothing
magical about signature parameters. The one thing that would need to be mentioned is
that there is no significance to the parameter names -- there would be no iana
registry or anything like that. The client and server would just need to agree
to their names and functionality which is nothing different than any other parameter.

 > The server would get the key:
> 
> curl -H "Accept: application/ld+json" https://dev.payswarm.com/i/manu/keys/3
> 
> look for the owner of the key in the data, which would be:
> 
> https://dev.payswarm.com/i/manu
> 
> fetch that profile:
> 
> curl -H "Accept: application/ld+json" https://dev.payswarm.com/i/manu
> 
> and then see if it has that identity on record as having an account on
> the server. If it does, then it would verify that the key is owned by
> the profile and check the validity of the signature.

I don't know whether this is relevant, but HOBA doesn't require third parties.
It's just a get-rid-of-passwords-as-currently-deployed scheme. As such, it
doesn't require 3rd party trust, somebody else's business model, etc. Just drop
hoba in and deprecate passwords being stored on servers. I for one would be happy to
see a spec that limits itself to just the client server problem so that web
sites can get their heads around even that smaller problem without them exploding
when you drag 3rd party complexity in.


> 4.3.  Authentication Phase
> --------------------------
> 
> The last part of the first paragraph and the last 3 paragraphs should
> just say that each topic covered is out of scope. The vast majority of
> this section deals with things that are out of scope for HOBA (and most
> HTTP Auth schemes).
> 
> 4.4.  Logging in on a New User Agent
> ------------------------------------
> 
> The vast majority of this section is out of scope for this spec as well.

I think you might be taking this draft way too literally. At least from my
vantage point, the idea in HOBA for the here and now is to sketch out how
this kind of idea could work, and the discussions about session, etc, is
to illustrate how it might work with real world sites today with real world
session management, etc. That is, you shouldn't read too much normative into
this draft.

> 
> 5.  Using HOBA-js
> -----------------
> 
> I don't understand why HOBA-http cannot be accomplished via JavaScript
> and XHR? Why do you need an entirely different way of encoding the HOBA
> protocol using only URL-based parameters?

The current draft is an amalgamation of two ideas that are generally similar.
I had independently come up with HOBA-js and then noticed Paul and Stephen
working on something similar. My idea was to use javascript+crypto libraries
and do this entirely at the application layer. Obviously webcrypto would be
a huge help, and get rid of dodgy js crypto libraries but it isn't available
yet.

This blog post documents what I did.

http://rip-van-webble.blogspot.com/2012/06/using-asymmetric-keys-for-web-joinlogin.html

I actually have a live implementation that does this. FWIW, it uses time stamps instead
of nonces for replay protection.

> Unless I'm missing something, the entirety of this section is at the
> wrong level of abstraction and unnecessary.

It shows that this can be done today, and that it doesn't even require standardization.
The reason I put it out there is because crypto is hard to get right, and even if it
doesn't _require_ standardization, standardization is a good way of getting clueful
eyeballs on would-be crypto deployments.

Mike