Re: Human readable credentials?

Thanks very much to those who took the time to reply. This has given me a
number of new angles to consider.

On Tue, 9 Jun 2020 at 11: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..
>
> 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
>
>
>
>