GGF Authorization Frameworks and Mechanisms Working Group

GGF7 Meeting 2, Thu Mar 6 2003 18:00-19:30

Comet room, Hotel Intercontinental Keio Plaza, Tokyo


Slides are available at:
http://zuni.cs.vt.edu/grid-authz/ggf7-2003-03-06.pdf
http://zuni.cs.vt.edu/grid-authz/ggf7-ProposedTerms.pdf


Agenda:

1. Discussion of outline + content of conceptual framework and
classification document (75 min)
2. Wrap up, planning of intermediate sessions (15 min)

Minutes (by Jim Basney):

Mary Thompson presented the terms that David Chadwick sent on the
mailing list.
  • Initiator (ISO): An entity (e.g. human user or computer-based
entity) that attempts to access other entities.
Alt: user, client (OGSA), authorization subject
  • Target (ISO): An entity to which access may be attempted.
Alt: resource, service, server (OGSA)
  • Authority (IETF): An entity, responsible for the issuance of
certificates. [assertions]
CA (x.509 certificate issuer) (IETF)
Attribute Authority (IETF)
Access policy authority (new)
Alt: Authorization Source

Group discussion:
In document presented by Von Welch at OGSA Security WG
meeting earlier today, initiator can ask PDP if it has permission,
and PEP can ask on behalf of initiator. There are different types
of clients. Is it a privilege asserter?
Is Authority the PDP or the thing that gives the PDP rules
it operates in? It is the latter.
What type of assertions are we talking about? All of them.
We're talking at a high level.
Are you an authority when creating a proxy certificate? Yes.
Is there a difference between Issuer and Authority? Anyone can issue
anything but doesn't necessarily have authority. PDP determines
authority. Issuing is a process while authority is something you
have.
What was wrong with Source of Authority (SOA)? Objection to the
abbreviation. What's the difference between Source of Authority and
Authority? What do you call the top authority? Root CA vs. trust
anchor.

Next set of terms presented by Mary:
  • Access control policy / rules (ISO): The set of rules that define
the conditions under which an access may take place.
Alt: Authorization policy, security policy
  • Access Request
  • Contextual Information: Info about or derived from the context in
which an access request is made (e.g. time of day).
Alt: environment variable (IETF)
  • assertion:
- doesn't have to be signed
- should use SAML's definition
  • certificate: signed document
  • credential: data that is transferred to establish claims
- identity credential
- access control credential
- Alt: Evidence (SAML)
  • delegation
  • privilege

Group discussions:
Matt Blaze's RFC on KeyNote has different definitions?
Credential is certificate and private key. It's what you need to
prove an attribute. Password is also a credential. Credentials
have a private component.

Markus asked for consensus on these terms.
Loud humming from the group.
Will be confirmed on the mailing list.

Leon Gommans reviewed his initial proposal (ASH, AAH, SOH) and a
version updated with new terms (SOA, ADF, AEF) and asked, do we need
to distinguish between the instance and the function (AS vs. ASH, for
example)?

Krishna Sankar led a discussion on the framework document.
Don't need Profiles and Conformance sections.
Can we collapse 4.2 (XML) and 4.3 (XML Web Service)? Yes, but we
should point out which are web services.
Do we need to include resource owners in the framework? Not clear.
Needs to be added:
- software to generate authorization tokens
- repositories for storing tokens
- more? (please send to mailing list)
Channel requirements should be noted.
How high-level a framework should we do? Is Leon's model at the right
level? Yes. Implementation-specific details, such as how
credentials are created and stored, will not be included.
Need content for existing services and modules (PERMIS, Akenti, OGSA).
Discussion of existing services is a jump to lower-level.
Yes, this is useful.
The framework needs to be general enough to describe existing
services. May need an additional framework layer, between
high-level framework and description of existing services. An
architecture layer?
Who will use this document? Will OGSA Security WG use it?
Goal is to provide guidance to developers of AuthZ systems by
summarizing existing systems.
We need to identify authors for the sections.
David Chadwick volunteered to help.

Krishna reviewed AuthZ specifications in OGSA Security Roadmap, which
should be addressed in the framework document.

Markus asked if there was interest in holding WG meetings before GGF8.
Dane suggested setting a date and working via teleconference.
Target date for first complete draft: May 1
Individual sections should be written earlier!

Meeting adjourned!

/public/users/mlorch/Grid-AuthZ/GGF7 AuthZ2 Minutes Login | Web Editor | Full Editor
Last modified 3/6/03 10:30 PM by mlorch (history)
Site contents