OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: secret token authentication


We haven't really talked that much about the details of authentication in XDI.

One mechanism that has recently been implemented is authentication via a secret token (password), which can be done with a link contract policy.

Example graph:

()/$is$ref/([=]!:uuid:91f28153-f600-ae24-91f2-8153f600ae24)
([=]!:uuid:91f28153-f600-ae24-91f2-8153f600ae24)/$ref/()
(=markus)/$ref/([=]!:uuid:91f28153-f600-ae24-91f2-8153f600ae24)
$do/$all/()
$do$if$and/$true/({$from}/$is/[=]!:uuid:91f28153-f600-ae24-91f2-8153f600ae24)
$do$if$and/$true/({$msg}$secret<$token>&/$equals/$secret<$token>&)
$secret<$token>&/&/"s3cr3t"

Example message:

([=]!:uuid:91f28153-f600-ae24-91f2-8153f600ae24)/$set/[=]!:uuid:91f28153-f600-ae24-91f2-8153f600ae24[$msg]!1
[=]!:uuid:91f28153-f600-ae24-91f2-8153f600ae24[$msg]!1/$do/$do
[=]!:uuid:91f28153-f600-ae24-91f2-8153f600ae24[$msg]!1/$is()/([=]!:uuid:91f28153-f600-ae24-91f2-8153f600ae24)
[=]!:uuid:91f28153-f600-ae24-91f2-8153f600ae24[$msg]!1$do/$get/()
[=]!:uuid:91f28153-f600-ae24-91f2-8153f600ae24[$msg]!1$secret<$token>&/&/"s3cr3t"

So, using the $equals operator, the link contract policy compares the secret token in the message with the secret token in the graph.

However, while this works by elegantly applying standard XDI constructs, there are (at least) 2 problems with this:

1. The secret token is stored as clear text in the graph. Not very secure.
2. This approach makes it impossible to set up XDI endpoints for a legacy system that already has a database of users and (probably hashed) passwords.

My thinking is that the solution is to partially move the authentication logic outside of the XDI graph.

For example, instead of saying the following in the link contract policy:

$do$if$and/$true/({$msg}$secret<$token>&/$equals/$secret<$token>&)

we could say something like this:

$do$if$and/$true/({$msg}$secret<$token>&/$auth/true)

Not sure if the syntax is great, but the idea is that the policy would evaluate to true, if the secret token is correct, without defining in the graph how to check its correctness.
The actual check would then happen outside of the graph, through some extensible mechanism of the server. We could call this an "XDI authentication connector", just like there are "XDI data connectors".
This I believe would also make it possible to implement password recovery and similar functionality in flexible ways.

Hope we can discuss this on tomorrow's call.

Markus



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]