[JDEV] SSI Protocol draft 1

[Dirk-Willem van Gulik]

> Here it is. Dead simple. And not finished. But you get the idea.

Though I appreciate that this 'forwarding' is very similar to the passport
idea's - I am not quite sure it is needed at all.

I think there are two options at a high level - which collapse into one if
with some careful trust management.

->	You(*) trust a site enough to 'auth' with it. In that case
	just adding a sign on protocol to the web server is your
	solution; i.e. http://research.covalent.net/->auth_jabber
	or something along those lines.

	You: as in 'you the end user'.

->	You do not quite trust the web site enough to authenticate
	with it - but enough to give them access to part of your
	details. So you need to prove to some third party, which
	is also trusted by the web site you want to identify yourself
	with, that you are who you say you are.

And in the latter case you need to pick up a singed cookie somewhere else,
or there needs to be some second channel, etc. Or something else. However
in all cases you are actively willing to entrust the site with -some-
information (some token, a uid, etc). Now you can use that as a toehold.

Now given that that is the case - why not make the sign on such that it
cannot be replayed, reused or anything like that. I.e. by making sure that
when you talk to the half trusted side - it has enough to auth you with
the backend system - but not enough to abuse what it learns.

For examply by using a one time challenge or one time password, by
proxying through an https connection to the authing backend (with
appropriate cert's), by letting your IM pop up an OK window fed through a
back channel. by having the IM show you a 4 digit PIN, RSA SecureID like
tricks, OTP calculators, etc, etc. All of which can be hidden - at the
client side or at the server side where appropriate.

Dw

> Authentication Protocol
> Draft 1
>
>
> The following elements represent the different actions that are
> available in the Single Sign-In Protocol.
>
> The following terms are used in this document:
>
> Client - users software (web browser, ftp client etc. that is not
> directly connected to the jabber network).
>
> Host - users host (for instance, jabber.org).
>
> Requester - the entity that wishes to authenticate the Client with the Host.
>
>
>
>
>
> At the start of a SSI transaction, the Requester should interrogate the
> Host to determine what authentication options are available. The first
> version of this protcol will define 3 types, however, more may be added
> at a later date.
>
> The following message is sent.
>
> <beginTransaction xmlns="http://jabber.org/ssi"/>
>
> and the Host sends back:
>
> <transaction id="02343151" xmlns="http://jabber.org/ssi">
> 	<authType name="web"/>
> 	<authType name="service"/>
> 	<authType name="im"/>
> </transaction>
>
> The Requester now has a transaction ID that can be used in subsequent
> messages.
>
> The Requester now sends something like this:
>
> <signIn id="02343151" xmlns="http://jabber.org/ssi">
>    <authType name="web">
>    	<template>http://requester/ssi-template.html</template>
>
> <return-url>http://requester/signin?key=SOMEVERYLONGRANDOMUNGUESSABLENUMBER</return-url>
>    </authType>
> </signIn>
>
> and the Host sends back when successful
>
> <instructions id="02343151" xmlns="http://jabber.org/ssi">
> 	<authType name="web">
>
> 		<redirect-url>https://signin.host/go.pl?id=02343151</redirect-url>
>
> 	</authType>
> </instructions>
>
> Note that the redirect-URL can be anything, the fact that the
> transaction ID features in it in this example doesn't indicate this has
> to be the case.
>
> The Requestor then sends an HTTP Redirect to the Client. The Sign-in
> program loads up the file specified in the <template> element of the
> <signIn> message, and then interpolates the form into that page
> (Passport calls this co-branding) and sends it to the Client. Once the
> Client has submitted their credentials, they are cleared, and sent back
> to the return-url. The sign in page can set cookies so the credentials
> don't have to be re-entered. The Requestor site can also set a cookie
> with the user name in, so the Client will not have to reauthenticate in
> future.
>
> ______________________________
> Michael Hearn
> mhearn at neuk.net
> Jabber (jabber.org) tweedledee at jabber.org
>
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
>