Re: Range of Security : Nonce

On Wed, Apr 23, 2014 at 6:38 AM, Melvin Carvalho
<melvincarvalho@gmail.com> wrote:
> On 23 April 2014 11:41, Anders Rundgren <anders.rundgren.net@gmail.com>
> wrote:
>> On 2014-04-23 11:29, Melvin Carvalho wrote:
>> > On 23 April 2014 02:56, Manu Sporny <msporny@digitalbazaar.com
>> > <mailto:msporny@digitalbazaar.com>> wrote:
>> > ...
>> >     Perhaps we should expand it to allow xsd:string, xsd:base64, and
>> >     xsd:hexBinary. Would that work for you, Melvin?
>> >
>>
>> May I ask how a receiver is supposed to understand what the actual coding
>> is?
>> Is coding a part of the message as well?  Seems a bit complicated in my
>> opinion.
>>
>> If there are no other constraints (which I know nothing about), I would
>> select
>> either string or base64.  Base64 is simpler since UTF-8 characters are
>> somewhat difficult to deal with since they can be 1-3 bytes long.
>
> Sure, in Linked data any literal can have a type.  In this case the type
> will be xsd : hexBinary
>
> This is already baked into JSON LD which is one advantage over other
> serializations
>

If a nonce is defined as more than one type then it is a bit tricky.
The raw JSON value will be a string in any of those cases so something
will have to signify which of xsd:string, xsd:hexBinary, or xsd:base64
it is.  Inline {@type:, @value:} usage would work but I assume most
people will prefer simplifying their JSON via a type define in the
context.  If that's done then anyone trying to process the nonce value
will have to look in the context to see what type is currently in use.
 I'm not sure if any JSON-LD libraries are yet advanced enough to
easily get this meta info.  This is all doable, but kind of a mess at
the moment, and probably needs library API support.  One easy approach
to all this is to punt on the issue and just define nonce as one type
such as hex or base64.

-dave

Received on Wednesday, 23 April 2014 15:24:36 UTC