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] $word(s) for digest-based comparison

We discussed that on the call - the password or other authentication secret must be sent over a secure channel. It should never be stored in plaintext on the server.

On Tue, May 21, 2013 at 2:44 PM, Joseph Boyle <planetwork@josephboyle.net> wrote:
If we are passing around the plaintext password, something is wrong. We don't want to be responsible for holding and possibly leaking this - authentication components should encapsulate the hashing and comparison.

On May 21, 2013, at 2:21 PM, Drummond Reed <drummond.reed@xdi.org> wrote:

From the minutes of last Friday's TC telecon:


Markus then ran through the scenario of the XDI endpoint interfacing with an external password store. This exercise highlighted that even if the XDI message authentication token is sent via a secure transport (such as HTTPS), it is not accurate for an XDI link contract policy to use an $equals comparison operator because that operator is for to compare equivalent literal values, and the external password store has a hashed/salted value.

We ran out of time to complete the discussion, but agreed to the following action item:

# ALL: Suggest a new $word to express the semantics of “secure comparison”.


In thinking about this action item, I like the idea of using XDI specialization, i.e., the ability to modify an entity, attribute, or relation by putting it in the context of another.

In this case, the relation is $equals. The base definition of $equals is an exact match between two XDI literal values. The modification we need for this use case is that it's not an exact match between literal values, but a match between the digest of one literal value and a second literal value (that is already a digest).

So one natural language way to say this in English is "digest comparison", i.e., make a digest, then compare it. To convert that into XDI specialization would suggest:


Although this specializes a $equals comparison to become a digest comparison, it is still very general, i.e., the XDI endpoint evaluating a $digest$equals comparison operator still needs to call code (or an external authentication service) that knows what kind of digest to compute for the comparison. That's fine, but if a particular link contract policy needs a particular kind or strength of digest comparison, it can further specialize $digest$equals. For example:



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