Re: [Drip] terminology: certificates & claims

So if I have reread this a few times and attempted to map what was said
here to DRIP explicitly:

Claim: a predicate where an entity (say Bob) owns an identifier (an HHIT)
[aka: Bob owns HHIT]
Assertion: a set of 1 or more claims. An HHIT as an ID for UAS RID is an
assertion. It's an assertion of a unique hash (which happens to point to an
asymmetric keypair of which only Bob should have the private key), and it
belongs in a registry (specified by the bits of the HID).
Attestations: a signed assertion. For us this is when we use the private
key of an HHIT and sign stuff - at minimum the HHIT/HI pair, or between
different parties (Registry and Operator for example) to assert
relationships.
Certificates: a narrowed definition of identities being signed by a third
party.

Claims are weak here. "Bob owns HHIT". That doesn't stop me from saying
"Adam own HHIT". Hence an Attestation is used to officially bind Bob and
HHIT together. This is what I refer to in my drafts as Certificate: X on X.
Yes it is an attestation but more specifically its a Certificate (as it
fits the definition of Certificate I declared above).

When Bob wants to become a member of a registry he is ultimately going to
provide his Certificate (on himself) and get back another certificate:
mainly Certificate: Registry on Operator. Again this is an attestation; but
it might still fit in the Certificate definition (third-party signing
[Registry], only identities and their relationships being asserted).

An example of an Attestation would be the "Offline Claim" Bob has been
discussing recently (formerly known as Certificate: Registry on Aircraft).
It's actually a multi-layered assertion. First is that the Registry attests
that the HI/HHIT keypair is valid until an expiration time and that it
approves it (using its signature). Then during a flight the UA itself
further asserts that the Attestation made by the Registry is valid (until a
given time) by signing it.

Does this make sense to anyone else but me?

On Wed, Oct 28, 2020 at 1:23 PM Card, Stu <stu.card@axenterprize.com> wrote:

> I hate to chime in agreeing that anyone (myself or another) should do
> additional work, but if you have the cycles, it should be a useful
> reference for authors and editors.
>
>
> On Wed, Oct 28, 2020 at 12:02 PM <michael@palage.com> wrote:
>
>> Henk,
>>
>> Totally agree the matrix needs to be extended.  My original choice was
>> based upon some of the internal discussion within the medical community. I
>> just found out that the matrix helped steer the discussion and provided a
>> nice internal document for the engineers that were focused on standards and
>> the lawyers that were focused on national laws.
>>
>> If others see potential benefit, I would be open to adding a RFC4949
>> column and a DRIPs column.
>>
>> Best regards,
>>
>> Michael
>>
>> -----Original Message-----
>> From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
>> Sent: Wednesday, October 28, 2020 11:58 AM
>> To: michael@palage.com; 'Michael Richardson' <mcr+ietf@sandelman.ca>;
>> 'Stuart W. Card' <stu.card@axenterprize.com>; tm-rid@ietf.org
>> Subject: Re: [Drip] terminology: certificates & claims
>>
>> Hi Michael,
>>
>> a very preliminary observation:
>>
>> This table could definitely use an RFC4949 (or IETF, but that is way more
>> effort) column.
>>
>> Viele Grüße,
>>
>> Henk
>>
>> p.s. as a hint - Claim, Relying Party, and Verifier are used extensively
>> in the RATS WG:
>>
>>
>>
>> On 28.10.20 16:50, michael@palage.com wrote:
>> > Hello All,
>> >
>> > Attached is a document that I created in connection with some identity
>> work that I have been doing in the medical space. I created it because
>> there was confusion about certain definitional terms across different
>> standards and frameworks between the lawyers and the engineers.  I find
>> this matrix is an interesting cheat sheet to make sure that everyone is
>> operating from a common definitional framework.
>> >
>> > If the group finds any value I could expand the matrix to include some
>> of the DRIP definitional terms.
>> >
>> > Best regards,
>> >
>> > Michael
>> >
>> >
>> > -----Original Message-----
>> > From: Tm-rid <tm-rid-bounces@ietf.org> On Behalf Of Michael Richardson
>> > Sent: Wednesday, October 28, 2020 6:57 AM
>> > To: Stuart W. Card <stu.card@axenterprize.com>; tm-rid@ietf.org
>> > Subject: Re: [Drip] terminology: certificates & claims
>> >
>> >
>> > Stuart W. Card <stu.card@axenterprize.com> wrote:
>> >      > (3) Certificates consist of one or more claims, plus some
>> evidence supporting
>> >      > those claims, typically a signature of a trusted [third] party
>> attesting to
>> >      > the truth of the claims.
>> >
>> > What Carsten and Henk said.
>> > I haven't seen
>> >    "evidence supporting those claims"
>> >
>> > in any actual (PKIX) certificates.  The point of the third party is
>> usually that it provides the service of evaluating the evidence, and this
>> has, until
>> > RFC8555 (ACME) been completely non-standard as to process.
>> >
>> >      > Carsten? Michael? Anyone? Thanks!
>> >
>> > Remember that it works best if you say our name three times in front of
>> the bathroom mirror.  :-)
>> >
>> > --
>> > Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT
>> consulting )
>> >             Sandelman Software Works Inc, Ottawa and Worldwide
>> >
>> >
>> >
>> >
>> >
>>
>> --
> Tm-rid mailing list
> Tm-rid@ietf.org
> https://www.ietf.org/mailman/listinfo/tm-rid
>

-- 
73's,
Adam T. Wiethuechter
AX Enterprize, LLC