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: Re: [xdi] Authentication



This just doesn't make sense... it would be a lot of work for nothing.
Supporting OIDC is much less work than having the TC define authentication methods that will be used by nobody in the real world.

- Mike



On Fri, 6 Jul 2012, Markus Sabadello wrote:

I would like to support passwords just to be able to test link contracts
easily, without having to set up an OpenID Connect server.
Also, to design the link contract authentication mechanism to be extensible
from the start.

My understanding of oxServer is that you would use some configuration file
to specify what kind of tokens are accepted, right?

Does oxServer use the "policy" literals? If yes, could you send some
example Javascript that would go into such a policy?

Markus

On Fri, Jul 6, 2012 at 4:01 PM, Michael Schwartz <mike@gluu.org> wrote:


TC:

In version 1 of XDI, I propose that we only define authentication
leveraging OIDC tokens. We cannot boil the ocean...

The demand for SAML token validation in XDI messages will be non-existant.

Authentication with password? I don't think we'd add any value over how
OIDC has defined this. Why on earth would we do this?

PKI authentication mechanism? The use case is military? Let the military
provide some resources to make it happen. Otherwise, OIDC seems sufficient
and can even incorporate two factor authentication.

So the very simple solution is the one we are using today in the oxServer:
require $token in the message unless it is an "anonymous" request to
$public.

- Mike




On Fri, 6 Jul 2012, Markus Sabadello wrote:

 So I am interested in the TC's opinions on how an XDI client can
authenticate to an XDI server.

Link contracts specify authorization (i.e. who can do what under what
conditions).
My understanding is that the link contract also specifies what
authentication methods it allows.

I am thinking several authentication methods should be supported:

- Authentication with OpenID Connect token:
The client includes a token in the XDI message.
The server or the link contract would have to know what tokens would be
accepted (from which issuer, etc.)

- Authentication with SAML token:
Similar to OpenID Connect.

- Authentication with signature:
The client includes a signature in the XDI message.
The server or the link contract would have to know what signatures would
be
accepted (certificate from which authority, etc.)

- Authentication with password:
The client includes a password (or a hash of it) in the XDI message.
In this case, the server or the link contract would have to know the
correct password for a given sender.

So I am thinking, a link contract must specify
1. The allowed authentication method(s).
2. For each authentication method, the details (see above).

Should this information be expressed by additional XDI statements on the
link contract?
Or is all of this part of the policy nodes, i.e. expressed in JavaScript?
The downside of expressing authentication in JavaScript is that an XDI
client can't ask the question what kind of authentication is needed.
Would some (or all) of the authentication information (e.g. a list of
valid
passwords) be "hidden" on the server and not visible in the graph or in
JavaScript at all?

Are there any examples out there, e.g. from OpenXDI?

thanks
Markus


------------------------------**------------------------------**---------
To unsubscribe, e-mail: xdi-unsubscribe@lists.oasis-**open.org<xdi-unsubscribe@lists.oasis-open.org>
For additional commands, e-mail: xdi-help@lists.oasis-open.org





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