Subject: [abfab] Fwd: I-D Action: draft-howlett-abfab-trust-router-ps-03.txt

From: Rhys Smith <[email-masked]>
Date: Tue, 12 Mar 2013 13:35:44 -0400

Hi all,

FYI, a new version of a problem statement driving the reasoning for needing trust router has been posted. There's still a lot of work needing doing on it. Compared to previous versions, this is trying to articulate the problem in a more general sense than has previously been done, to see if that helps in explaining the problem.

Rhys.

Begin forwarded message:

> From: [email-masked]
> Subject: I-D Action: draft-howlett-abfab-trust-router-ps-03.txt
> Date: 11 March 2013 18:25:28 EDT
> To: [email-masked]
> Reply-To: [email-masked]
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title           : Trust Requirements in a Federated World
> 	Author(s)       : Josh Howlett
>                          Rhys Smith
>                          Margaret Wasserman
> 	Filename        : draft-howlett-abfab-trust-router-ps-03.txt
> 	Pages           : 14
> 	Date            : 2013-03-11
> 
> Abstract:
>   TODO: This document outlines the requirements for trust in a
>   federated environment, and enumerates the requirements for a trust
>   infrastructure.  It also examines existing trust infrastructures
>   given these requirements and concludes that none fulfil all of the
>   requirements, and suggests that maybe a new one is required that
>   does.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-howlett-abfab-trust-router-ps
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-howlett-abfab-trust-router-ps-03
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-howlett-abfab-trust-router-ps-03
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 12 Mar 2013 13:50:51 -0400

Here is also a good document related to this topic: 
http://tools.ietf.org/html/draft-mrw-abfab-multihop-fed-02

On Mar 12, 2013, at 1:35 PM, Rhys Smith wrote:

> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

---

From: Sam Hartman <[email-masked]>
Date: Tue, 12 Mar 2013 14:08:26 -0400

>>>>> "Hannes" == Hannes Tschofenig <[email-masked]> writes:

    Hannes> Here is also a good document related to this topic:
    Hannes> http://tools.ietf.org/html/draft-mrw-abfab-multihop-fed-02

The multihop federation document is somewhat out of date.
we believe that the introductory text  from that document has been
migrated to the new protocol document.

--Sam

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 12 Mar 2013 14:22:04 -0400

Btw, I never understood why Josh, Rhys, and Margaret suddenly started a new document. 
I like draft-mrw-abfab-multihop-fed-02 more.

---

From: Rhys Smith <[email-masked]>
Date: Tue, 12 Mar 2013 14:33:25 -0400

There's a separate document so as to separate out a description of the problem from the solution we've designed (trust router) that tries to solve the problem.

So the latest version of an attempt to articulate the problem is at http://tools.ietf.org/html/draft-howlett-abfab-trust-router-ps-03 and the newest version of the trust router solution is at http://tools.ietf.org/html/draft-mrw-abfab-trust-router-02

Rhys.

---

From: David Chadwick <[email-masked]>
Date: Tue, 12 Mar 2013 18:48:54 +0000

Hi Rhys

having read your draft could I suggest

1. some changes in terminology

Trust Arbitrator - > Reputation Service or Reputation Service Operator 
depending upon context

Trust Advisor - > Root of Trust

These two entities are quite different, but by using very similar 
notation for both, as you do, it tends to conflate them into being 
almost the same. I would prefer it if different terms could be used, 
that a) better describe their functionality, and b) better differentiate 
between them. It would also remove the tautology from this sentence

A Trust Arbitrators/Advisors can attempt to become the arbiter of
        trust for multiple communities.

2. that you have downplayed the complexity in establishing technical 
trust between entities. Joining an Authentication Policy Community might 
actually be quite time consuming and tedious, if you have to prove that 
you conform to a certain set of policies (e.g. LOA 3).

3. wrt section 5.1, the scientific EGI community might strongly disagree 
with your conclusions here. I think they think that PKI works just fine, 
is infinitely scalable and very secure. But you should check with them.

regards

David

---

From: Josh Howlett <[email-masked]>
Date: Tue, 12 Mar 2013 20:58:40 +0000

Hi Hannes,

The problem statement was written as a response to feedback that
draft-mrw-abfab-multihop-fed did not explain the problem that the
architecture it describes is meant to address, so they're doing different
things. I agree that draft-mrw-abfab-multihop-fed is a more interesting
document if you're sold on the problem.

Josh.

>> migrated to the new protocol document.

Janet(UK) is a trading name of Jisc Collections and Janet Limited, a 
not-for-profit company which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 12 Mar 2013 17:18:50 -0400

Hi Hannes,

We were advised by the ABFAB Chairs that we needed to get consensus on a problem statement before we could work on the solution documents in ABFAB.  The -ps document were an attempt to document a problem statement for that purpose.

I think that all of the still-pertinent information in the multihop-fed document has been moved to the Trust Router protocol document, and multihop-fed has been abandoned.  Let me know if I've missed anything you would like to see preserved.

Margaret

---

From: [email-masked]
Date: Tue, 12 Mar 2013 23:24:09 +0200

I didn't know that you had decided to move text into the new -ps document and to abandon the document that I co-authored with you.

Hannes

Margaret Wasserman <[email-masked]> wrote:

>
>Hi Hannes,
>
>We were advised by the ABFAB Chairs that we needed to get consensus on
>a problem statement before we could work on the solution documents in
>ABFAB.  The -ps document were an attempt to document a problem
>statement for that purpose.
>
>I think that all of the still-pertinent information in the multihop-fed
>document has been moved to the Trust Router protocol document, and
>multihop-fed has been abandoned.  Let me know if I've missed anything
>you would like to see preserved.
>
>Margaret
>
>

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

---

From: Gabriel Lopez <[email-masked]>
Date: Wed, 13 Mar 2013 17:39:56 +0100

Hi,

    Just a few comments about the ps

Section 1. Introduction   
    - "two entities are able to verify that each other is who they think
they are" --> the term "think" is quite ambiguous here,  probably better
"two entities are able to verify that each other is who they claim they
are""

Section 2. Terminology
    - Authentication Policy Community (APC): "A set of entities that
share a common trust infrastructure" It is just a "federation"? Why the
term policy is used here? It is just for authentication not for
authorization?

    - Community of Interest (CoI): Does it refers to idPs and SPs (and
principals/clients?)
    
    - Entity: A general term for IdPs and RPs.
        In documents like
http://docs.oasis-open.org/security/saml/v2.0/saml-glossary-2.0-os.pdf,
the general term for idPs and RPs is "Provider", in fact, "Entity" is a
more general concept"

   - Trust Arbitrator: What is a "trust rating"?

    - Trust Advisor:
            - CoR is not defined
            - Agree with David, "Root of Trust" is a well known term for
that, or even "Trust Anchor"
            -
Section 3.

    3.2 - Authors remark the term "Communities of Trust", which is not
included in Section 2.
    3.2 - "and users of it typically need to pay for the service". Does
it refer to the fact of paying for trust? I usually connect to my bank
account, trust is established based on a Trust Anchor (probably
something like Verisign), but I have never paid for this trust? Or have
I misunderstood the sentence? Could you add some examples?
    3.2 - " Trust Arbitrators are less commonly seen, and are usually
found where a Trust Arbitrator stands to make financial gain" Is it this
sentence right?
    3.3 -  Does this section describe something similar to the term
"confederation" or "alliance"?

 Section   5.1 - Have you take into account cross-certification? Bridge
CA? etc....
            -  "Works well but only when governance and management is
done properly" --> Well I think it is true for any kind of
infrastructure/technology/scenario I can imagine ...
            - "Which it isn't, generally" -- > Agree with David. This is
a very strong sentence.
   
 Section 6 -
   
    It is still difficult to me to see the real problem to be solved. I
expected a description about how technologies like ,for example, PKI
does not fulfils the requirements of section 4. I'm not saying it does,
I'm just saying it would improve the problem statement... 

    Sorry if I'm saying nonsenses, just trying to understand the
terminology ....
   
    Regards, Gabi.