W3C home > Mailing lists > Public > semantic-web@w3.org > February 2010

Re: password datatype in RDF

From: Reto Bachmann-Gmuer <reto.bachmann@trialox.org>
Date: Fri, 5 Feb 2010 00:07:48 +0100
Message-ID: <bfcea8c71002041507n478e1602vba23089bc101cf78@mail.gmail.com>
To: Jeremy Carroll <jeremy@topquadrant.com>
Cc: James Leigh <james-nospam@leighnet.ca>, Semantic Web <semantic-web@w3.org>
Hi Jeremy,

There are many situation where storing or even transmitting an
unencrypted password can and should be avoided, but I don't think
that's the question here.

As I understand the question, it's if using a datatype is the right
solution to express in rdf that a particular string is a password and
agents rendering the information of the graph correctly display it as
sequence of '*'-characters.

I think there are many cases where the typical representation of the
information contained in a graph does not implies displaying literal
values without applying a function dependent on there location in the
graph.

For example in the incubating apache clerezza projects an image is stored as:

<rdf:Description rdf:about="http://localhost:8080/image">
    <rdf:type rdf:resource="http://discobits.org/ontology#InfoDiscoBit"/>
    <disco:infoBit
rdf:datatype="http://www.w3.org/2001/XMLSchema#base64Binary">/9j/4AAQSk....=</disco:infoBit>
    <disco:mediaType
rdf:datatype="http://www.w3.org/2001/XMLSchema#string">image/jpeg</disco:mediaType>
    <j.1:dateSubmitted
rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">2010-02-04T23:46:37.411+01:00</j.1:dateSubmitted>
    <exif:width
rdf:datatype="http://www.w3.org/2001/XMLSchema#int">92</exif:width>
    <exif:height
rdf:datatype="http://www.w3.org/2001/XMLSchema#int">92</exif:height>
  </rdf:Description>

Typically when represing the above resource to a human an image would
be shown rather than just the result of applying the the
xsd:base64Binary interpretation function to /9j/4AAQSk....=. I don't
think that it is wise to introduce higher level interpretation
functions, neither for images nor for passwords. The code presenting
the form with the password should be able to conclude from the
location within the graph that the string should not by default be
shown on a screen.

Cheers,
reto

On Thu, Feb 4, 2010 at 11:31 PM, James Leigh <james-nospam@leighnet.ca> wrote:
> On Thu, 2010-02-04 at 09:34 -0800, Jeremy Carroll wrote:
>> I seem to have received advise about how to store passwords, but
>> actually my question was about how to represent passwords in RDF.
>>
>> In my use case the password is typed in by a user, and later (perhaps
>> week's later) presented by the system to another application.
>>
>
> You should try and encoded the password as soon as possible. In the case
> of a web application, using JavaScript to encode it. I don't see a any
> difference between the need to encoded stored passwords and the need to
> encoded transmitted passwords.
>
>> This means that my system needs to be able to access the text (not just
>> the encrypted text) that the user typed in.
>>
>> I see this as essentially one triple:
>>
>> eg:account eg:password "secret text that needs to be protected when
>> stored or on the wire or in a display" .
>>
>
> I think a blank node resource is more appropriate option here. Consider:
> eg:account eg:password [a eg:Secret;
>        eg:encoded "939e7578ed9e3c518a452acee763bce9"^^xsd:hexBinary;
>        eg:algorithm "MD5"].
>
> RSA could also be used for the algorithm with another property for the
> key used. You can then have your UI display resources of type eg:Secret
> as ***s and (if needed) make it easy for the user to decrypt the secret
> text.
>
> James
>
>
>
Received on Thursday, 4 February 2010 23:08:18 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 21:45:34 GMT