RE: [External] [xdi] Authentication

I propose that rather than deciding which methods to explicitly support, we instead create a generic authentication mechanism, i.e. something like SASL. If XDI messaging were a connection-oriented protocol then I would suggest an XDI binding of the SASL abstraction layer. However, to my knowledge XDI messaging has always been, and is intended to remain, a connectionless protocol (or more precisely a message-oriented protocol).

Also, for the most part I do not think we should do the bits of security piecemeal. I think we need to provide the framework for an XDI message sender to choose to ensure all, some, or none of confidentiality, integrity, availability, and non-repudiation.

Availability is something to address later, outside the core spec, and my take is possibly controversial as my vision of it involves the XDI communication path being Sender ->Sender’s Information Agent (I-Agent) -> Receiver’s I-Agent -> Receiver

I propose the following hierarchy of $ words to address message confidentiality, integrity, non-repudiation, and authentication, which I’ll write into a proposal on the wiki.

()

$sec

$sig (addresses integrity, may be used to address authentication, non-repudiation)

$typ (the type of signature mechanism used)

$opt (options for the signature)

$val (the signature)

$enc (addresses confidentiality)

$typ (the type of encryption mechanism used)

$aud (this describes the intended audience for this portion of the encrypted text)

$lev (this describes the security level of the encrypted text, which together with $aud determines authorization)

$opt (options for the encryption, such as algorithm used)

$val (this contains encrypted version of the rest of the message, unencryption populates the message)

$auth (addresses authentication, possibly non-repudiation)

$typ (the type of authentication credentials used)

$opt (options for the authentication mechanism used)

$val (the credentials, e.g. JWT, SAML Token, etc.)

Notes:

1) In the wiki proposal the $sig working with the $enc details will be layed out

2) $enc is designed to allow multi-instances, to allow for encrypting different msg portions separately to support tearlines

3) User of $sig, $enc, $auth, and in point of fact $sec, is optional by the spec. Use is intended to be governed by implementors, and governance policy

4) An example of the current $JWT modified to use $auth would be (note that these are implicitly in the message’s context graph):

$sec$auth/$typ/$sec$auth$typ$jwt

$sec$auth$val/!/(data:;base64,eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ)

eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ.dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk)

5) #4 uses the literal notation prior to the currently under discussion version

6) The supported types and options would be specified in a link contract, as Markus pointed out.

Kind regards,

Bill Barnhill

Booz Allen Hamilton - Belcamp,MD

1-443-924-0824| barnhill_william@bah.com

From: xdi@lists.oasis-open.org [mailto:xdi@lists.oasis-open.org] On Behalf Of Markus Sabadello
Sent: Friday, July 06, 2012 7:12 AM
To: OASIS - XDI TC
Cc: Mark Horstmeier; Chowdhury, Animesh
Subject: [External] [xdi] Authentication

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

xdi message