[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 canauthenticate 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]