[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Minutes of 15 May 2001 Security Services TC/Focus telecon
Thanks to Bob Griffin for taking the notes!
Minutes of the OASIS Security Services Technical Committee telecon
and the Focus Subcommittee telecon
15 May 2001
Please note the ACTION items below. If you see anything that needs
correction, please reply to this message.
Administrative
==============
- Membership report: new/removed members
We didn't get a full report, but we have 58 members.
- Roll call
Attendance list appears at the end of these minutes. Quorum reached
with 30 voting members.
- Approval of minutes for F2F #2:
http://lists.oasis-open.org/archives/security-services/200105/msg00006.html
Approved.
- Approval of minutes for the last telecon:
http://lists.oasis-open.org/archives/security-services/200105/msg00040.html
Approved.
- Approval of/additions to this agenda
Accepted with insertion of discussion of OASIS Conformance TC as the
first item.
Discussion of OASIS Conformance TC
==================================
Lynne Rosenthal and Mark Skall joined us briefly. The Conformance TC
was formed about a year ago, partially in response to the XML/XSLT
conformance work and the need to share it. The goal of the TC is to
share information about conformance in general; it serves as an advisory
body (white papers, etc. are posted at the NIST website) and it
represents NIST and OASIS at ebXML meetings. They also work with W3C on
quality initiative.
Review the running list of open ACTION items
============================================
ACTION: Bob Blakley to develop and circulate a Word template for all
specification contributors to use. STATUS: no progress yet; try for
Monday 21 May.
ACTION: Bob Blakley to work with Phill Hallam-Baker to develop the
simplified architectural model and coordinate it with the proposed
Core Assertions design. STATUS: BobB understood this as simplification
of assertion data structures, rather than as model as a whole; about
done with that.
NEW ACTION: BobB to update assertions based on Phil's doc distributed
yesterday.
NEW ACTION: All members to review Phill's spec. Phil will be away for
two weeks; comments should go to the TC list.
ACTION: Bob Griffin to attempt to map the proposed Core Assertions
design to our requirements. To be done by 11 May. STATUS: need to
distinguish two docs (examples and mapping). Example doc has been
published by Phill. (Phill: Pieces are still needed in example doc: for
example, exactly how you request, particularly for the subject: eg PEP
might give account name but want common name back.)
NEW ACTION: Conformance group to start reviewing the traceability
of use cases against Phill's design and release a rough draft for review
before the next TC telecon.
NEW ACTION: Prateek to do traceability review before the next TC
telecon.
ACTION: Hal Lockhart to publish a fresh issues list. New deadline: To
be done by 18 May.
ACTION: Hal Lockhart and Dave Orchard to update the Architectural
chapter to reflect F2F #2 decisions. Hal to update his picture today.
Dave O to update whole chapter by 11 May. STATUS: put on hold for next
two weeks. Credential collector and session had been out; pass-through
authentication has re-opened the question. Gil suggested that session
should be an overlay picture in any case.
NEW ACTION: Agreement that for now session stuff should be taken out,
cardinality information and other changes should be done. DaveO to send
out chapter by Friday 18-May.
ACTION: Jeff Hodges to update the Glossary to reflect F2F #2 decisions.
New deadline: to be done by 18 May.
ACTION: Darren Platt to update the requirements document to reflect F2F
#2 decisions and publish as a consensus draft ASAP. STATUS: draft was
sent last night to security leaders. Eve would like to finalize doc in
order to make it public; should have group review before wrapping it
up, hopefully at focus group on Tuesday 22-May. To be done by 18 May.
NEW ACTION: Eve to create Evite page with F2F #3 information.
NEW ACTION: Prateeek to produce draft of bindings doc to go to whole
group by Tuesday 22-May.
NEW ACTION: Raj will sent out info on DSML.
NEW ACTION: Dave Orchard to send out URLs for XML protocol related
to binding.
NEW ACTION: Darren to add this requirement to requirements doc.
NEW ACTION: Hal to add new issues collected at this meeting.
(Are AnonymitySupport, DisposableValidity, TimeSkew, NameVsHandle, and
ValidityDependsOn good names?)
NEW ACTION: Prateek will create or point to a use case for
ValidityDependsOn.
Review plans for F2F #3
=======================
- Evite poll results: will be 25-26 June in Menlo Park, CA.
- If we don't reach quorum, is a Focus subcommittee meeting
acceptable? We will probably have quorum for that date; if
not, OK to do it as Focus subcommittee.
- Goals for this F2F:
. Review and approve as much of the design as possible
. Assess plans for implementation and conformance
. Figure out the end-game schedule
Eve wants to come out of F2F meeting with design substantially
complete; lots of work to do, especially some big decisions. General
response was doubt that can make such a goal. Eve: at next F2F have to
be brutally honest about going forward, particularly in terms of
reaching the September date or slipping 3 months.
Concern about the quality/completeness of the writing, including
issues such as protocol completeness. Hal: trade-off likely to be
regarding precision of information in spec.
Subcommittee reports
====================
- Focus (Eve)
Made a recommendation to TC to authorize new subgroup to evaluate
pass-through, with Stephen F. as chair (see below). Also info on
tutorials on XML sent out by Eve.
- Sessions (Hal)
Initial doc by Dave; concall on it last Thursday firming up and
agreeing on the requirements. Also started a section on design
goals/tradeoffs, eg timeliness of updates vs efficiency of updates.
- Bindings (Prateek)
Had concall last week and week before. In first concall, reviewed a
set of slides elaborating those from F2F; one thread is "binding
assertions to payloads"; second thread is terminological issue of
getting right terms for what binding subgroup is doing (Jeff has
circulated draft of this). Next meeting is Thursday noon.
- Conformance (Tim)
Status: BobG/Krishna to arrange call this week or next. Goal of
strawman by two weeks.
- Considerations (Jeff)
Status: no activity published in last week. Has been discussed as
context in various subgroups. Jeff has been looking into other
information to draw on. Goal of getting something out in next one or
two weeks.
Liaison reports
===============
DSML: new DSML 2.0 proposal.
ebXML: Maryann. Last meeting last week, specifications published to web
site; ongoing work by steering committee to coordinate across
organizations; SAML coordination was recommended (messaging
specification and collaboration protocol subgroups). No significant
authentication or authorization has been identified yet for ebXML;
expectation that SAML assertions will need to be bound into payload or
message.
XML protocol: discussion about actor attribute and "must understand"
which relates to binding of SAML and SOAP; particularly relevant to
issues such as routing rules. For example: "Actor = SAML intermediary"
would mean that SAML intermediary would have to understand some portion
of the header.
XKMS: workshop on 19 July, same place (San Francisco) as XML encryption
on 20 July which has been announced; still looking at finding a chair.
Hal: what is expectation on spec? Phill: workshop goal would be to
discover whether the spec is complete; also discussion of extensions
such as bulk load into smartcard, using it with WAP; and discussion of
aligning with XML protocols will also require some modification to spec.
Technical issues to discuss/approve
===================================
- Focus subcommittee recommendations:
http://lists.oasis-open.org/archives/security-services/200105/msg00051.html
. "We recommend that the TC authorize a subgroup/task force to
evaluate a suitable pass-through authN solution for eventual
inclusion in V.next of SAML. If the TC likes the design once it
is presented, it may choose to open up its scope to once again
include pass-through authN in V1.0. Stephen is willing to champion
this."
Moved and seconded. No debate or objections; passed.
. "Direct the editor of the requirements document (Darren) to
indicate that we desire a design where signatures and encryption
are optional."
Discussion: three possible options for signing (none; mandatory;
optional) Moved and seconded. No debate or objections; passed.
Open mike (new issues)
======================
- Requirement for anonymous and pseud-anonymous is not met by current
assertions doc. At moment, assertions requires that there be a
subject. Pseud-anonymous means that identity does not map to real-
world identity; question is one of registration; Phill can accommodate
this in the design.
Darren read the two requirements. Pseud-anonymous will be done;
anonymous is issue. Should anonymous be supported?
- Hal would like to have a way by which assertion that is valid cannot
be cached. Possible issue about time-skew, not met by validity period;
when talking about authorization decision assertion, may need to have
short life-time where clock-skew is an issue. Would like to have
explicit way of calling out that assertion is one-time-only: "one-
use". Bob: "Time-of-check to time-of-use problem". (If done by setting
validity interval, then if clock is wrong the assertion may not be
usable even once.)
- General issue of whether one worries about time-skew is separate from
the above issue.
Prateek: wondering how the object will fit into infrastructure. BobB:
what does it mean that assertion can be used only once?
Hal: PEP gets assertion, with proviso: "if you want to ask about this
assertion, ask me again."
Adjourn
=======
Adjourned at 1:20 pm EDT. Continued with focus group meeting.
Focus subcommittee agenda
=========================
The following list is from Hal, our issues list maintainer. Please see
recent discussion on security-services and Phill's new version of the
core assertions draft:
http://www.oasis-open.org/committees/security/docs/draft-sstc-core-06.pdf
Phill reviewed what had changed in the Core Assertions draft:
- Filling out the claims section
- Going through and correcting typos etc.
- Removed "validity depends upon", based on F2F discussion
- Expanded explanation of respond element, particularly what kind
of assertion is expected
- Changed subject specification to explicitly specify name of
principal or pass credential
- Two ways of identifying: by name or by something they have. Bearer of
the assertion needs to be discussed; is this bearer of the assertion
itself (changes when assertion is passed to someone else) or bearer of
a ticket (ticket can be used as subject). With syntax currently, can
support bearer of assertion; binds to person who can present the
private associated with public key or can present a password that
matches digest or plain-text password (should allow both).
Name vs. handle issue:
BobB: three cases are nominative (subject contains name); descriptive
(subject contains ticket); indexical (bearer).
Marlena: for Shibboleth, need user handle. Could use name; but handle
is not the same as the name, but rather used to retrieve attributes
and can change from day to day.
Phill: change from nameID to principalID?
Marlena: handle is not really a principal, since not something which
would be put on ACL.
Hal: way to solve anonymity problem? BobB: also solves other things;
solving anonymity is part of larger "how to we refer to subjects in
assertions problem".
Phill: in terms of datatypes, one of them was Unicode name of subject,
useful when you want to put subject's name up in page saying welcome
etc; the other is some means of machine identifier (perhaps make
element name more neutral, something like subjectID). Doesn't need to
be long-term identifier of principal, but must be a member of the set
identified for the duration of the validity interval.
Eve: can name be bound to short-term handle?
Phill: as long as the binding of name to handle is ok for the validity
period of the assertion.
Marlena: need handle to link up request/response.
Phill: proposal is that nameID element (type URI) remains type URI but
renamed subjectRef (analogous to HREF), and we write a section how to
use that with handle, with account name and so on.
BobB: and distinguished value meaning bearer of assertion.
Phill: might need to register URN types.
Hal: other than anonymity, are there other important requirements
being met?
BobB: question uppermost is "we have to refer to subject in
assertions; even if we don't address anonymity; there are reasons to
do things like bearer refs that don't have to do with anonymity; so we
need to keep in mind anonymity when designing schema that supports
referring to subjects, but larger issue is that we don't have a design
for referring to subjects.
Discussion of "Validity depends on" issue:
Prateek: assertion could be generated in pieces; with attribute
assertion pointing to authentication assertion. How would this be
accommodated?
Phill: point raised at F2F is that if validity is not in scope, then
validity-depends-upon in not in scope either. (?)
Hal: could have a bunch of assertions that all refer to same subject;
using same subject would tie them all together?
Phill: yes, having same subject is way this issue would be addressed.
Hal: a single assertion that had a bunch of claims would be equivalent
to a bunch of assertions with a single claim each.
Prateek: need to check this against the use cases.
Marlena: don't have a use case for this; however, could be a case
where you get an attribute from one authority only if another
attribute was obtained from another authority.
Hal: if you want to say a is true if b is true, but cannot revoke b,
what value is the syntax? BobB: yes, don't have a fully-formed set of
rules.
Prateek: atomic assertion validity; on top of that, some assertions
might depend on others (a composite form).
BobB: objection is that the only way to get a NO response is they go
out of time scope.
Carlisle: another case is that depending assertion can't be verified
(essentially doesn't exist for the party verifying the assertion).
Marlena: by value vs by reference assertion.
BobB: have to evaluate assertion guts.
Marlena: yes, will be necessary in some cases.
Hal: relying party is free to have policy that requires a,b,c to be
true; asserting party wants to be sure that no one uses this info
unless other assertion is true.
BobM: expressing policy?
Prateek: attributes that are conditioned on authentication act?
Marlena: could also be on other attributes.
Carlisile: doesn't have to refer to an assertion.
Phill: keen on "depends-on"; but doesn't make sense unless we have the
other piece. Plan to address this later version? Other piece is we
need a general mechanism for tracking assertion status, such as
revoking assertions.
Carlisle/Prateek: no, depends on does not require revocation.
Prateek: change in SAML core assertions is causing debate in removing
of "depends-on" element.
Marlena: depends-on does not have to be on assertion. If you had a
time of under 3 hours in NY marathon, get to be in Boston marathon.
Hal: need use case.
Prateek: need to distinguish depends-on for assertion (reference to an
assertion) vs extension where depends-on anything else.
DaveO: risk here of circularity?
Prateek: may need to constrain number of levels, recursion, etc.
Discussion of XMLAssertionGenerality (aka "top vs. bottom"):
Hal: why bottom-up makes him uneasy? If we assume we can have
authorization decisions that might not mention a subject, but some
attribute that might be shared, then suppose someone sends assertion
that has Joe/DR/access=fileX. Asserting party might have meant
something different from what receiver understands, because the
assertion does not define itself as authorization assertion or
authorization decision assertion. Semantic ambiguity is caused by not
distinguishing the kinds of assertion.
Eve: same guts could apply in different ways, if assertion types are
distinct.
Phill: way to distinguish is whether role is subject or object. At
moment, explicitly cannot specify role as subject; may need to remove
this in order to satisfy anonymity?
Marlena: don't need to put role into subject; too close to expression
of policy.
Phill: no way of saying that doctors are allowed to access file; that
is policy.
Hal: unidentified person is doctor, then in effect have said that all
doctors can access file.
Phill: no, issue of how the assertion is used.
BobB: "clairvoyance" concern. To write top-down, understand only what
input to provide; to write bottom-up, have to know a lot about answer
in order to ask the right question.
Eve: sentiment running against "bottom-up"? Not clear yet. Need
concrete examples of problems; want to explore what is truest to all
of our requirements and goals.
Phill: would like to see concrete example of problem caused by bottom-
up.
--
Eve Maler +1 781 442 3190
Sun Microsystems XML Technology Development eve.maler @ east.sun.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC