Re: Human readable credentials?

On Tue, 9 Jun 2020 at 12:46, Greg Mcverry <jgregmcverry@gmail.com> wrote:

> A bit off topic, but I have been fooling around with webmentions and
> credentialing using microformats which are both human readable and machine
> readable. I dig keeping my content and metadata in one HTML file..
>

Hi Greg

I like this approach.  The only gotcha here is that meta data and actual
data are slightly different types of things.

So if you mix the two you can sometimes get undesired effects.  The way to
future proof such things in the Linked Data world is to use the:

"@id": "" pattern

For your meta data.  This can be quite confusing for the average web
developer.  I remember spending some time explainging this to Sandeep
Shetty (who invented webmention) and I finally go tthrough with the
analogy:  "You might like Ricky Martin's home page but you might not like
Ricky Martin".  Careful observers will of course know this as that infamous
"HTTP Range 14" problem.  But the problem actually goes away if you tie
meta data to the "@id": "" part.  More familiarly you can consider it
similar to putting data in a document in different places:  meta data in
"head", and actual data in "body"

I think this woudl work quite well, there's a bit of fiddly corner cases
around embedding and signign, but and I'm enjoying experimenting here.  It
also aligns the data models more closely of projects like VC and Solid
leading to a more interoperable eco system with larger network effect.


>
> On Mon, Jun 8, 2020 at 4:40 PM Daniel Hardman <daniel.hardman@evernym.com>
> wrote:
>
>> > Human-friendly representations are derived from the machine-friendly
>>> ones, keeping them in sync
>>>
>>> >
>>>
>>> That is most certainly one way to approach the problem.  But it is not
>>> the only one.  For example, I can show you how to deterministically produce
>>> a machine readable representation from a human-friendly one.
>>>
>>
>> Agreed. I wasn't claiming otherwise. What makes either approach helpful
>> is that the correspondence is guaranteed.
>>
>>
>>> > Putting a B64 encoded block into a valid credential is not introducing
>>> a lot of new risk if the processing entity for that chunk is still
>>> software.
>>>
>>> >
>>>
>>> Sorry but I have to disagree with you on that one.  If one processor
>>> knows how to decode that B64 block and present it and another processor
>>> does not – which is perfectly acceptable since I can have custom contexts
>>> in my VC’s – then you have the same situation you have pointed out.
>>>
>>
>> You are correct. I was assuming it was the *same* software interpreting
>> both parts.
>>
>>
>>> > The problem arises when there are two potentially divergent
>>> representations, and the two processing entities are disjoint. *That* is an
>>> exploitable gap.
>>>
>>> >
>>>
>>> That is **ONLY** an exploitable gap **IF** the two representations are
>>> physically separate from each other **AND** not signed/sealed
>>> together.  However, if the two are signed as a single entity, then you
>>> can’t modify one w/o invalidating the other, the preventing any form of
>>> exploit.
>>>
>>
>> This seems to contradict your previous statement "If one processor knows
>> how to decode... and another processor does not...". Physical separation
>> isn't what creates the gap, as you pointed out. The problem is different
>> and independent processing. This could happen even if two representations
>> are in the same physical file and signed as a unit (your example about
>> custom contexts).
>>
>>>
>
> --
> J. Gregory McVerry, PhD
> Assistant Professor
> Southern Connecticut State University
> twitter: jgmac1106
>
>
>
>