RE: [External] Re: [xdi] Authentication

["Barnhill, William [USA]" <barnhill_william@bah.com>]

Mike,

I will point out two things.

1) Several years ago the same email as yours could have been written responding to OpenID instead of passwords, and 'Supporting OIDC' changed to 'Supporting SAML'.   Each set of users will have different use cases, and different security concerns, and these will change over time.   This may be why SASL is so popular. It is why I wrote the proposal I did and emailed it to the list.  That proposal would allow OXServer to still only support OIDC, albeit do so using a different set of XDI statements.  The proposal would also allow PKI and the password approach Markus is talking about.  Trying to come up with the one size fits all security mechanism and mandate that as the mechanism for XDI will confine XDI to a niche adoption community.

2) Yes the military, and NGOs, are one potential set of adopters.  Is there a reason to exclude them from XDI? To my knowledge, and in my own opinion, OIDC is not allowed by US Government policy on federal and DoD systems.  Therefore if OIDC is adopted as the XDI authentication mechanism, XDI will not be allowed either.  The solution of 'let them come up with something else' will not work.  They will likely not, instead deeming XDI unsuitable due to lack of support for mandated security mechanisms.  If we had massive buy-in, like Linux, then a higher security version of XDI might be created.  It is unlikely it would be fully interoperable with the TC's XDI.   This is one reason why I think it is important to prescribe a security framework that allows for any mechanism, present and future, to be supported.  See my previous email today for one take on the $ words to make up that framework.


Kind regards,
 
Bill Barnhill
Booz Allen Hamilton - Belcamp,MD
1-443-924-0824| barnhill_william@bah.com
 


> -----Original Message-----
> From: xdi@lists.oasis-open.org [mailto:xdi@lists.oasis-open.org] On Behalf
> Of Michael Schwartz
> Sent: Friday, July 06, 2012 11:14 AM
> To: OASIS - XDI TC
> Subject: [External] 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-op
> >> en.org> For additional commands, e-mail:
> >> xdi-help@lists.oasis-open.org
> >>
> >>
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xdi-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: xdi-help@lists.oasis-open.org