GGF12 OGSA Security & Naming design team session #6
Sept 22 3:30pm-5:00pm
Minutes: Olle Mulmo 
(some text added by Takuya Mori 
 in the part of Frank's and Takuya's presentations)
===================================================

Frank introduced the topic of the session: how to obtain secure names.

Andrew Grimshaw: Secure Grid Naming Protocol (SGNP)

- Andrew (re-)presented SGNP (last presented at GGF4)

- Motivation: resources need to be named, identified and authenticated
  across domains
  -> a single unified namespace
  -> location transparent (for migration)
  -> scale to billions/trillions

- Discussion on Naming vs Identity
  - Dave S: SGNP should really be called SGIP

- SGNP is based on LOIDs (location-independent object identifiers)
  - immutable for the lifetime of the resource
  - globally unique
  - URI format (loid://<domain>/<id>/<secutiry info>)
  - contains "security info" (public key for authentication
    verification)

- LOID is not integrity protected
  - depends on trusted initial delivery (and that you don't screw up
    once you've got it and trusts it!)

- SGNP defines binding and rebinding protocols
  - asynchronous, cacheable

Sam Sun: The Handle system

- Global Naming Service (handle.net)
  - Used by library community
  - Documented in 3 RFCs
  - two-layer naming scheme: <domain>/<any-string>

- Security features
  - protocol option for integrity and confidentiality
    - returned message with handle data also carries reference to
      signature (for trust)
  - administration: handle owner administers his/her handles
    - administrative burden can be shared (delegated)
    - {public/administrative,read/write} permissions can be granted
  - hierarchial tree of services (like DNS) with a single root server
    operated by CNRI
    - TTL on a resolved handle defines caching capabilities

- License issues
  - only available for free to academics right now, due to operational
    costs of root service
  - this may go away soon thanks to our own dear and relentless Frank

Frank Siebenlist:

- Names vs. Intrinsic Names discussed
  - intrinsic: undeniable and verifyiable by relying party
  - example: globally unique name (file URL) + hash (md5sum)
  - all other names require a _trusted_ external binding

- EPR equivalence
  - latest WS-Addressing draft has rules for comparing EPRs
  - discussion on some details on the fundamentals
    - WSRF is defining a comparison mechanism of EPRs for 
      idengifying WS-Resources
    - Equivalence of an ERP is only meaningful with in a paritcular
      context or an addressing domain
    - EPR is lack of uniquness over time

- Suggestion: EPR Intrinsic name
  - generate EPR-Id (intrinsic name) by hashing the canoncialized
    properties of the WS-Address element (including reference
    properties), as specified by the WSA equivalence rules on EPRs
  - relying party can independently can now verify the integrity of an  
    EPR using the EPR-Id

- What names do we care about?
  - The policy rules that are enforced determine what attributes/names
    are required

- Policy Example
  - Some trust mechanisms are needed for a "name" and an EPR mapping.
    * "name" here seems to mean some sort of human readable names??
      (ex: "John's bank account at citibank"...)
   -> These mappings or bindings need some sort of TTPs.

Takuya Mori: Use cases for EPR resolution (and where to put the trust)
- Use cases
  - Use cases for "Trusted Directory Service" and "Untrusted Directory
    Service"
  - The requirement for naming scheme heavily depend on the trsut model
    for binding mechanisms

- Conclusion
  - First, we should agree on the trust model

---- end of the minutes