Subject: [saag] Vectors of Trust (VoT)

From: Justin Richer <[email-masked]>
Date: Sun, 13 Nov 2016 11:09:49 +0900

Hi all,

The Vectors of Trust draft was published to this list back in July for comment, but no discussion was received at the time. We would like to move this forward as an AD-sponsored informational RFC (under Kathleen’s aegis). 

The current draft is available here (it hasn’t changed since July):

https://tools.ietf.org/html/draft-richer-vectors-of-trust-03 <https://tools.ietf.org/html/draft-richer-vectors-of-trust-03>

We’d appreciate review and any commentary that people might have before this document goes to the next step.

Thank you,

 — Justin

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 13 Nov 2016 05:27:17 +0000

I took a quick read of the draft.  Why are some values 0 1 2 and others are a b c?
Why isn’t the on-the-wire representation identical for openid saml and trustwave?

--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: [email-masked] Twitter: RichSalz

---

From: Justin Richer <[email-masked]>
Date: Sun, 13 Nov 2016 14:32:49 +0900

Rich,

Thanks for the review and your questions.

The numeric values are intended for components that have a natural order and potentially subsumptive definitions. Identity proofing, for example, is usually going to just get *more* proofed. The alphabetic values are intended to be for more set-based components that may or may not have a full overall natural order. Authentication methods, for instance, might have a loose order to them but won’t likely have a universal single order. We intended to have communicated this in the following paragraph, but I would be happy to make this clearer if we can:

   The value for a given component within a vector of trust is defined
   by its demarcator character followed by a single digit or lowercase
   ASCII letter in the range "[0-9a-z]".  Categories which have a
   natural ordering SHOULD use digits, with "0" as the lowest value.
   Categories which do not have a natural ordering, or which can have an
   ambiguous ordering, SHOULD use letters.  Categories MAY use both
   letter style and number style value indicators.  For example, a
   category could define "0" as a special "empty" value while using
   letters such as "a", "b", "c" for normal values can to differentiate
   between these types of options.

On the wire formats: I agree they should be the same, and they will be before this goes final. Notably, the SAML example needs to be updated to use the same on-the-wire representation as OIDC. I’ve reached out to a couple of SAML gurus for help with getting that done properly. What’s in there now is from an old draft and I’m not enough of a SAML person to take a stab at it myself.

Thank you,
 — Justin

> On Nov 13, 2016, at 2:27 PM, Salz, Rich <[email-masked]> wrote:
> 
> IM: [email-masked] <mailto:[email-masked]> Twitter: RichSalz

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 13 Nov 2016 05:34:47 +0000

Glad to hear there will be a single wire format.  I’d offer to help with SAML but have frankly purged most XSD and SAML from my working set.

Thanks for the explanation, but I don’t think a natural ordering makes sense: is a thumbprint better than voice?  Shrug, YMMV.

---

From: Justin Richer <[email-masked]>
Date: Sun, 13 Nov 2016 14:36:37 +0900

> On Nov 13, 2016, at 2:34 PM, Salz, Rich <[email-masked]> wrote:
> 

This is precisely why the authentication method category doesn’t use numbers — I’ve seen (online) fights break out over this! :) Letters still convey *some* order, but it’s less of an implied rank than a digit.

 — Justin

---

From: Steve Crocker <[email-masked]>
Date: Sun, 13 Nov 2016 14:52:52 +0900

Use colors.

Sent from my iPhone

> On Nov 13, 2016, at 2:36 PM, Justin Richer <[email-masked]> wrote:
> 
> 
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Denis <[email-masked]>
Date: Sun, 13 Nov 2016 18:10:14 +0100

Hello Justin,

I have several comments on this draft:

1. The intended status of the document is unclear. The content of the 
draft states "Experimental" while the request is now for "Informational".
     Considering its content, it should not be Informational.

2. The introduction states:

This document defines a mechanism for measuring and signaling several 
aspects of digital identity and authentication transactions
that are used to determine a level of trust in that transaction.

    The wording "level of trust" is not adequate. Someone trusts (or 
does not trust) someone else for something. So it is a binary function.
    The title of the document" Vectors of Trust" is not adequate either.

3. IMO, the four orthogonal components considered in this draft : 
identity proofing, primary credential usage, primary credential management
     and assertion presentation are not adequate. This will be explained 
in detail later on in this email.

    An identity provider acting as a trusted third party on behalf of a 
user makes assertions about the user to the relying party.
    From the point of view of the relying party, there are two 
information when receiving a signed assertion that would need to be known:

1)the strength of the authentication mechanism that has been used 
between the user and the identity provider.
Such strength could be represented on a linear scale.

2)for each individual attribute present in the assertion:

a)*how***that attribute has been verified by the identity provider ?

and

b)*when*****(i.e. a date) that attribute has been /lastly /verified by 
the identity provider ?

How the verification of an attribute has been done might have two forms: 
"open loop" or "close loop".

To illustrate these concepts let us use the case of an attribute like a 
postal address.

    Case 1: Open loop: the postal address has been verified using a
    passport at the time the user presented the passport to the identity
    provider.

    Case 2: Close loop: Initially the postal address has been verified
    using a passport at the time the user presented the passport to the
    identity provider,
                    but the identity provider is sending from time to
    time a letter to that postal address that allows it to make sure
    that the user is still receiving letters
                    to that address.

Let us now consider the four dimensions of the vector proposed in the 
current draft:

    The current proposal considers the "Identity Proofing dimension to
    define, overall, how strongly the set of identity attributes have
    been verified and vetted".
    This approach mixes the previous concepts which is inappropriate.

    The current proposal considers the "primary credential usage
    dimension defines how strongly the primary credential can be
    verified by the IdP".
    This seems to map to the first information proposed here above: the
    strength of the authentication mechanism that has been used between
    the user
    and the identity provider.

    The current proposal considers the "primary credential management
    dimension conveys information about the expected life cycle of the
    primary credential
    in use, including its binding, rotation, and revocation. In other
    words, the use and strength of policies, practices, and security
    controls used in managing
    the credential at the IdP and its binding to the intended
    individual". This dimension should be merged with the previous one.

    The current proposal considers the "Assertion Presentation dimension
    defines how well the given digital identity can be communicated
    across the network
    without information leaking to unintended parties, and without
    spoofing". First of all, the "digital identity" should be
    generalized into "attributes".
    After reading the sentence several times, I must admit that I have
    difficulties to understand the meaning and the usefulness of such
    information
    fromthe point of view of a relying party.

IMO, both the content and the title of the draft should be changed. I 
would propose to consider:

-at the level of the assertion, the strength of the authentication 
mechanism that has been used between the user and the identity provider
before obtaining the assertion. Such strength would be represented using 
a linear scale.

-at the level of every attribute contained in an assertion, how (e.g. 
open loop or close loop) and when (e.g. a date)
that attribute has been lastly verified by the identity provider ?

This can be seen as :

    -  a "a single dimensional level of confidence" related to an 
assertion as a whole, and

    -  a "two dimensional level of confidence" related to every 
attribute present in an assertion.

Note that I am purposely using the wording "level of confidence" rather 
than "level of trust".

Denis

> Hi all,
>
> The Vectors of Trust draft was published to this list back in July for 
> comment, but no discussion was received at the time.
> We would like to move this forward as an AD-sponsored informational 
> RFC (under Kathleen’s aegis).
>
> https://tools.ietf.org/html/draft-richer-vectors-of-trust-03
>
> We’d appreciate review and any commentary that people might have 
> before this document goes to the next step.
>
> Thank you,
>
>  — Justin
>
>

---

From: Justin Richer <[email-masked]>
Date: Wed, 16 Nov 2016 15:49:43 +0900

Denis,

Thanks for the review of the draft and your comments on it. 

I’ve talked with Kathleen and we’re debating whether to move this to Experimental or keep it as Informational. Either approach is fine with me. 

I disagree that “Trust” is a binary term. I believe that it naturally has a gradient, even in digital systems like this, even if the final result of the authorization process is a binary decision. While I agree that “trust” is a loaded term, I believe it’s appropriate for use here.

Overall, while your insights are appreciated, it really seems to me that you’re looking for a different solution to a different problem from what we’re trying to solve here with VoT. I can hope that any such future solution would be compatible enough to be used in parallel where necessary.

Thank you,
 — Justin