5. Federation document

DavidG presents the current IGTF Federation Document.

Section 3.1 on the assignment of namespaces. Need to better define "authority"
DavidG interprets "authority" as the body which runs one or more CAs.
TAGPMA interprets authority as the CA.
DaveK points out that the AuthZ WG proposes to accredit Attribute Authority
Service Providers not the individual AA.
JimB suggests the term is "PMA Member".
If same DN is issued by more than one CA (belonging to one member) then
incident response is more difficult - all the CAs of the member are then
suspect.  If user credential is compromised, would have to revoke all
certificates issued to that person.
Jim: the positive sides are - subscribers find it very confusing to have
different DNs from different CAs.
Willy is concerned that there are persistent (e.g. storage) ramifications
of short-lived certificates.
DavidG sees advantages for user who starts with SLCS and then at later
stage wants to access other service and gets MICS cert - DavidG wants
this person to keep same name.
DavidG: sharing namespace between CAs should require a top-level policy
document on the management of the namespace by the PMA member.
Jim: I don't want to give VOMS admin rights to a person authenticated by
a SLCS CA. Can configure VOMS to use both user DN and issuing CA.
We agree proposed wording changes to Section 3 and 3.1.
This should also be discussed at the next TAGPMA and APGridsPMA meetings.
Reimer: Do we need to require the existence of the top-level namespace
management document? Only for new CAs wishing to use this. Could also
be common text in the two CP/CPS documents.