OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Minutes of 25-26 June 2001 Security Services TC F2F #3


=======================================================================
Minutes of OASIS Security Services Technical Committee F2F #3
25-26 June 2001
Jeff Hodges, editor.

this file: 	SSTC-F2F-3-Minutes-00.txt
  located:	http://www.oasis-open.org/committees/security/minutes/
  created:	6-Jul-2001


If you're an SSTC member, send any comments on these minutes to:
security-services@lists.oasis-open.org

Otherwise, send comments to:
security-services-comment@lists.oasis-open.org

========================================================================
Executive Summary
========================================================================

The OASIS Security Services Technical Committee held it's third
face-to-face meeting on 25-26 June 2001. The SSTC is working on
developing the Security Assertions Markup Language (SAML). 

The main high-level goal of the meeting was to achieve consensus on the
structure of SAML's "assertions" and the request/response protocols for
obtaining said assertions. We had two non-trivial proposals with
respect to SAML assertions and protocols going into the meeting. 

The meeting successfully resulted in consensus on an overall design for
Assertions and associated request/response protocols. The
authors/editors of the two prior proposals have agreed to work together
to refine the agreed-to design, extracting/leveraging appropriate
portions of the prior proposals in the process. The goal here is to
have an initial draft document out for SSTC review well before the next
SSTC face-to-face meeting in mid-to-late August (see below). 

We note that we have missed our original goal of having a specification
ready for submission for OASIS-wide review on 1-Jun-2001. We have
established new overall goals, which are..

  1. to have a "stable" specification by 1-Dec-2001
  
  2. to encourage the creation of "sample" implementations before
     1-Dec-2001,  and strongly encourage/support their creation after
     1-Dec-2001. 

  3. to submit the SAML specification for OASIS-wide review on
     1-Mar-2001 (for review process to begin 1-Apr-2001). 


In terms of future SSTC face-to-face meetings, we are planning to meet
in mid-to-late Aug-2001, and again in late-Sep-to-early-Oct. Details
are TBD via regular SSTC concall meetings and on the list. 


========================================================================
Introduction
========================================================================

Mucho thanks to Kelly Emo, RL "Bob" Morgan, Gil Pilz, and Darren Platt
for contributing their notes to these minutes! Mucho thanks also to Eve
Maler for hosting the meeting at the Sun Newark campus and working to
ensure our time there went smoothly. Also many thanks to Bob Blakley for
so effectively leading our in-depth design discussions.


These minutes, raw notes, and .jpg images of the whiteboards can be
found here..

  http://www.oasis-open.org/committees/security/minutes/

..there are specific pointers, to specific files, below where
appropriate.

One specific, normative doc to note here is..

  "SSTC F2F #3 -- Whiteboard transcription" (aka "WhbTrnscp")
 
http://www.oasis-open.org/committees/security/minutes/SSTC-F2F-3-Notes-Hodges-WhiteboardTranscription-01.pdf

..that file is also attached to the mail message version of this
document. It contains a thorough transcription (using Visio) of the
material upon the whiteboards from the meeting room at the end of the
second day. It (attempts to) captures all the various details --
textual and graphical -- inscribed on the boards. Thus we *shouldn't
have to* refer back to the .jpg images of the boards (tho they remain
as the ultimate backup of what was written). 


Below I focus on the results of detailed design discussion, straw
polls, and note the raised ISSUES as an (hopefully) official record. If
you have any corrections, please raise them as responses to this
message. 


Notation and terminology:
-------------------------

"assn" 		= "assertion"
"assnid" 	= "AssertionID" 	= "assertion identifier"
"attr" 		= "attribute"
"authn" 	= "authentication"
"authz" 	= "authorization"
"wrt" 		= "w.r.t." 		= "with respect to"

The term "the list", as used below, generally refers to the
security-services@lists.oasis-open.org mailing list, but might also
refer to a particular subgroup mailing list (e.g.
security-binding@lists.oasis-open.org) depending upon context. 

"ISSUE:[F2F#3-xx]:" identifies issues that were recognized as such by
the group. I numbered these issues sequentially within this document
after having otherwise completed said doc. It will be an exercise for
the issues czar (Hal Lockhart) to map these issues, or some appropriate
subset thereof, into the issues doc (draft-sstc-saml-issues-xx). 

Text in square brackets with a trailing "ed.", e.g. "[..., ed.]"
constitute notes on the contents from the editor. 

"[Fn]", e.g. [F1], signify footnotes. Footnotes are generally at the
end of the major subsection in which the first reference to them
appears. 

Major subsections are unnumbered and delineated by heading text
surrounded by "=============". Major subsections largely map to the
meeting chronology.

Normatively significant subsections are numbered using roman numerals,
e.g. I, II, etc. and are interspersed within major subsections. See the
listing of normatively significant subsections below. 

In expressing protocol requests in prose, e.g..

  Return (ANY | ALL) following attributes (#) for the subject (#).

..the "(#)" signifies that the thing preceding it is an argument of
the request, and thus may vary from request to request. Thus in the
sample request above, "attributes" and "subject" are postulated as
arguments of the request. 



Normatively significant subsections 
(i.e. the Table of Contents we need to pay special attention to)
----------------------------------------------------------------

I. Points we had (rough) consensus on wrt AuthnAssn, AuthnAssnReq, &
   AuthnAssnResp
II. Discussion and ISSUES wrt AuthnAssn, AuthnAssnReq, & AuthnAssnResp

III. Points we had (rough) consensus on wrt AttrAssn, AttrAssnReq, &
     AttrAssnResp
IV. Discussion and ISSUES wrt AttrAssn, AttrAssnReq, & AttrAssnResp

V. Points we had (rough) consensus on wrt AuthzDecAssn,
   AuthzDecAssnReq, & AuthzDecAssnResp
VI. Discussion and ISSUES wrt AuthzDecAssn, AuthzDecAssnReq, &
    AuthzDecAssnResp
    
VII. Points we had (rough) consensus on wrt Schedule Outlook, work
     signups, meeting dates, etc.
VIII. Discussion and ISSUES wrt Schedule Outlook, work signups, meeting
      dates, etc.



Abbreviations for some of the SSTC Draft Specifications Referred to below
-------------------------------------------------------------------------

"assertion-00"
 
http://www.oasis-open.org/committees/security/docs/draft-orchard-maler-assertion-00.pdf

"core-09"
  http://www.oasis-open.org/committees/security/docs/draft-sstc-core-09.pdf 

"protocols-00" 
 
http://www.oasis-open.org/committees/security/docs/draft-sstc-protocols-00.pdf



=============================
Meeting Agenda & Reading list
=============================

The agenda and document reading list for the meeting are here..

  http://www.oasis-open.org/committees/security/f2f3-25June2001.shtml#details

We made some on-the-fly agenda changes, as reflected in the minutes
below.  For example, we included the editor's report, had a lunch
breakout session  on the proposed commercial web browser SAML
profile. 

==============
Administrative
==============
[co-Chair (present): Jeff Hodges; co-Chair (not present) Joe Pato]

- Roll call

    Attendance list and membership status update appear at the end of
    these minutes.  Quorum was NOT reached. 

There was a motion to adjourn the meeting, seconded, not debated, and
thus the Chair adjourned the meeting. The TC will next officially meet,
as previously scheduled, via conference call on Tue 10-July-2001.

The attendees present decided to proceed with this meeting per the
agenda, under the guise of the Focus subgroup. 


================================
Subgroup Reports (Mon 25-Jun AM)
================================

Issues list - Hal Lockhart - 
--------------------------

very few issues "marked in yellow". Yellow indicates they are in active
discussion. 

Prateek reiterated 3 issues the bindings group has brought up on the
list recently:

  1. Use of the term "Profile" to describe another context's use of
     SAML components. For example "the SAML profile for SOAP" or "SOAP's
     profile of SAML". He noted that the unadorned term "profile" may
     conflict with use by the conformance group.

  2. Registration issues - where do we register things such as profiles
     of SAML and SAML protocol bindings? JeffH has recently pointed at 
     IANA (http://www.iana.org/) as a possibility.
     
  3. "Integrity of SAML message attachments".  I.e. how do we bind a
     SAML assertion to the message or  other object it attaches to?

Hal continued: 

He modified the "top/bottom" issue to reflect status of
draft-orchard-maler-assertion-00.

ISSUE:[F2F#3-1]: Issues List document is way too large. Need to stop
sending around dead issues. Discussion of ways to archive closed/dead
issues into a separate document.



Bindings - Prateek Mishra - 
-------------------------

Review of the [F2F-#3-specific version, ed.] bindings document
(draft-sstc-ftf3-bindings-model-00.pdf).

Hal: Is the intent to re-use protocol bindings in different
profiles ? Prateek: True, but not the core motivation behind the
distinction between "bindings" and "profiles".

General discussion about the semantics of "bindings" and
"profiles".

Prateek: SAML services have value within themselves. "Bindings" are
SAML-on-top-of-something. "Profiles" are SAML-within-something.

[these notions are discussed in gory detail, with illustrations, in the
2nd half of this message on the list...

  http://lists.oasis-open.org/archives/security-services/200105/msg00064.html

ed.]

JeffH noted that the intention is to do conformance work on both
bindings and profiles of SAML. 

Hal noted that discussion falls under the "Use of the term
'profile'" in the Issues List.

More general discussion about the terminology and semantics of
the term "profile". "Profile" is used in different ways by different
parts of the security community. JeffH: If we consistently stick to
"Foo profile of SAML" as an atomic term, things should work out.

distinguishing binding from profile:
  binding is "how to make SAML exchange happen, using underlying foo"
  profile is "how to make foo stuff happen, with added SAML components"

a shortened version:
  binding is "how SAML uses foo"
  profile is "how foo uses SAML"

-	Someone noted we need to talk about "protocol bindings" during
the Conformance group report.


ISSUE:[F2F#3-2]: Hal officially raises an issue - Doesn't understand
why protocol bindings are the subject of conformance.



Security & Privacy Considerations - Jeff Hodges - 
----------------------------------------------- 

JeffH noted that RLBob has drafted some security considerations in the
Shibboleth project. We can likely re-use portions thereof. 

The recent "Contradictory Requirements" thread on the list (instigated
by Tim Moses) is an example of security consideration issues.

   Carlisle:  A paragraph in considerations is all that is needed to 
   address that issue, the problem is solved in the bindings area.

When Assertions and Requests are nailed down this area (sec
considerations) will require some serious work.

Prateek: Concrete security considerations will probably revolve around
specific protocol bindings. Need to coordinate between Bindings group
and Security considerations group. 

Carlisle Adams: Pointing out problems is ok, but solving them is
better. [point well taken. Ed.]

Don Flinn noted/suggested that the "Common Criteria" may provide useful
and relevant information/guidelines. [see http://csrc.nist.gov/cc/  
ed.]




Sessions - Gil Pilz - 
-------------------

Gil Pilz's presentation:
http://www.oasis-open.org/committees/security/minutes/SSTC-F2F-3-DynamicSessions-Pilz.ppt

Progress slow because of press of other events

Major topics: (1) How do you register a session? (2) How do you find
out if a session is active? (3) Global user logout (4) Global
admin-forced logout.  Major problem is, how do you figure out globally
that a session has timed out?  Two algorithms being considered: (i)
Servers re-register their active sessions periodically with the session
authority. (ii) Session authority remembers approximate timeout
deadlines for local session authorities; when it thinks a timeout
deadline is coming up, it polls the local authorities to determine
whether the session has in fact timed out or not.

Prateek asks whether you've been considering that the local session
authorities don't necessarily know that a logout has occurred at the
global session authority.  Gil replied that this case isn't as bad as
the other case, since all you lose is local state if a local session
authority times a session out prematurely - you can still get the
session re-established transparently by using the authentication
assertions.


[unattributed summary from Kelly's notes. ed.]
How do you tell if a session has timed out?  

   1.	session authority does nothing until point in time where a
	global session looks like it is going to time out.  SA would
	then go and ask ea. Local session authority-do you have any
	info about sessions before I log it out?

   2.	local session authorities provide update to global session
	authority at periodic intervals. I.e. application server
	tells SA that it has the following X active sessions.


Hal observed that the extent in which a participant participates in a
session ecosystem only impacts their own risk, not anyone else's risk.

Gil observed: one can be completely SAML compliant yet not participate
in sessions.

ISSUE:[F2F#3-3]: Hal indicated he still had an open issue in his mind: 
How do you have some way of knowing that you have to worry about
sessions?  Perhaps use conditions mechanism in assertions?


Darren asks about this scenario - doesn't it effectively remove the
local session authority's ability to log a user off before the global
authority thinks the session has timed out (Because re-establishment
via authentication assertions will still give the user his session back
again)?  Some discussion follows.  Hal & Gil observe that local state
at the local session authority is flushed, and this is "as good as you
can do" and still have single signon at all.

Someone mentions that the local authority's policies might want to be
more strict than those of the global authority - e.g. the local
authority might want to have a 15-minute inactivity timeout whereas the
global authority has a 30-minute inactivity timeout.  The global
authority wins in this case, which is a violation of local autonomy
(!)  Can this be fixed?

Dave observes that the choice of algorithms depends on what you think
the relationship between global & local timeout values may dictate the
algorithm you choose.  If the global value is longer, then you want the
global session authority to poll.  If the local value is longer, you
want the local authorities to push to the global authority.

Someone observes that user-observable behavior needs to be
psychologically explainable.


ISSUE:[F2F#3-4]: Bob Blakley -	asks for a set of diagrams showing the
local and global "valid time" intervals and how they overlap, with an
explanation of what behavior we WANT to have - then let's design an
algorithm which implements that behavior.



PassThru Authentication - Stephen Farrell - No report. 
------------------------------------------



Editor's Report - Bob Blakley - 
-----------------------------

Separated out issues doc, glossary and bindings from protocol and
assertions.  Did not want to come up with a new rev of the spec ea.
Time someone comes up with a new binding.

Jeff: Proposing that we don't bundle the documents together just for
the meetings but rather have a set of references.

Bob: Ok with this, but wants "good" references. Final documentation
should look a lot like the current specification for F2F #3.

Krishna Sankar:  Bundling the documents together gives us a good idea
of what the spec will look like when it is done. Also easier to give to
other people.

Bob: This is dangerous as it gives external parties the idea that these
are drafts.

Hal: Mechanical point; draft-sstc-ftf3-saml-spec-00.pdf has unreadable
line numbers.

Jeff: We need to keep careful track over which docs are being revved
and which ones are stable. Mass confusion lies ahead if we don't get
our act together on this score.

Bob: Has included individual component drafts on the title page of the
combined docs. thinks roughly the structure we have now is workable. 
Protocols have to refer to the appropriate version of assertions etc.
Conformance tags are key: what do people have to read/build, etc.

Phil: Where is the Word template? Bob: Not done: Jeff: (with stick)
Whack! Bob: Ouch! Jeff: When the template comes out we need to revise
the current docs to use this template.

Evan: Some point about the bindings doc? Shouldn't pull out the
bindings document prematurely. Prateek: There are two parts to the
bindings document; framework and specifics. Should leave framework in
the main document and separate out the specific bindings stuff. Evan:
Presents counter-example.

ISSUE:[F2F#3-5]: we need the common Word doc template!!

ISSUE:[F2F#3-6]: doc repository needs cleaning-out. JeffH proposes
sweeping older, non-current doc versions into a subdir named "old".



Conformance group - Robert Griffin -
----------------------------------

(this session actually occurred towards the end of the day on Monday,
but is placed here along with the other subgroup reports for
convenience)

Robert Griffin's  presentation:
http://www.oasis-open.org/committees/security/minutes/SSTC-F2F-3-conform-Griffin.pdf


-	Two sets of docs:

   o	  In spec, conformance clause that Krishna wrote up

   o	  Separate from that, have a doc that is called something akin
	  to "the conformance program" which would walk you thru the
	  process of validating a SAML-based application/system.


-	Four major areas
   o	  Partitions (i.e., not "profile", but perhaps "conformance 
          profile")
   o	  Certification
   o	  Test Groups
   o	  Test Suite

-	Define and test conformance based on large chunks of
	functionality (basically aligned with use cases) rather than
	the behavior of individual components.

-	Not every SAML implementation will implement every aspect of
	every SAML function (for example various bindings)

   o	  Define conformance by calling out the supported bindings, or

   o	  Defining various levels of conformance, each level would have
	  a specific set of bindings associated with it

   o	  Differentiate conformance based on whether an entity produces
   
	  or consumes assertions and/or produce or consume SAML
	  request/response messages. For example, PEP's produce Authz
	  Decision requests, and consume Authz Decision response
	  messages containing Authorization Decision Assertions.


ISSUE:[F2F#3-7]: Is the proposal discussed over lunch (web browser
profile) yet another Conformance partition, different from the
Authentication Authority partition?  BB and PM believe this to be the
case.


-	Stating conformance on three levels

   o	  Running provided tests as a sort of self check

   o	  Certification by a third-party that attests that the above
tests completed successfully. No implied legal responsibility.

	   -	Jeff: "Certification" smacks of marketing and branding.
		RLBob: The natural organization for doing "certification
		and branding" is The Open Group.

   o	   ?????? <--- what was this third level?


-	"connect-a-thons" (e.g. DirConnect) are mentioned. It is
	clarified that the IETF *does not* "host" these. Rather, folks
	who're involved in various IETF-based efforts (e.g. directory and
	email protocols) have historically organized such events
	(typically hosted by some other appropriate organization, e.g. the
	Internet Mail Consortium) -- wherein various vendors to connect
	together, hook their their various implementations together, watch
	'em break, and work together to fix 'em [I've
	attended/participated in two of the DirConnects which were both
	regarded as *very* worthwhile by the participants. ed.].

  o	Eve suggests a connect-a-thon by F2F #4. The group-at-large
	seems to feel that that is way too early. Perhaps towards the end
	of 2001?


==============================================================================
Focus Group (aka Core assertions + request/response protocols) - Presentations
==============================================================================

Phill on draft-sstc-core-09 (aka "core-09")
-------------------------------------------

Presentation slides: Phill pointed at portions of..

  http://www.oasis-open.org/committees/security/docs/draft-sstc-core-09.pdf 

..while speaking. 

"assertion-00" refers to..

 
http://www.oasis-open.org/committees/security/docs/draft-orchard-maler-assertion-00.pdf


"bottom up" proposal has percolated up to be a "mid-level proposal".
Differences between Phil's proposal and the Orchard-Maler proposal are
decreasing.

SAML Assertion Package has an identifier.

Package is a set of data that has a unique identifier.

SAMLSubjectQuery - for each SAML request there is one, unique subject
that scopes that request. Bob: Does Subject here mean the same thing as
the Subject field? Phil: Yes. Prateek: Can you look up Assertions by
ID? Phil: Yes.

some key points:
    the query thing
      typical SAML query has a unique subject that it's about?
	this is "SAMLSubjectQuery"
      but "give me assertion with ID <alsjf>" doesn't have subject?
	so this would be a different type?
      new less-constrained SAMLXQuery could be another type ...
    "subject" doesn't necessarily mean "this well-identified principal"
      could just be "set of attributes", no? 


Differences between this proposal and assertion-00 is the query style.

SAMLXQuery provided for "fully unconstrained queries" in the future.
Phil does not like the idea of unrestricted queries but worries that
this will lead to sub-SAML balkanization.

Bob Blakley: (compares core-09 and assertion-00 w/respect to forming
queries that result in authorization decisions). Phil: Queries can
contain custom data and schemas.

Prateek: Can SAML authentication query carry authentication
information? Phil: We have moved away from the template model.

"Subject" may bind to a specific Principal, but it may not. Queries can
therefore be more open-ended than specific questions about specific
principals.

Dave Orchard: How do you know what the schema of the Extended
Attributes: Phil: Schema is negotiated out of band. General back and
forth about how you form queries based on open-ended schema. Phil: You
need domain-specific data to form queries on Extended Attributes.
Extended Attributes imply the necessity to extend the query language.



Dave Orchard on draft-orchard-maler-assertion-00
------------------------------------------------

[<placeholder for URL to Dave & Eve's presentation> ed.]


two proposals are growing closer together

some key points:
    re-use vocabularies
    use attributes
    define cardinalities for all assertions
         i.e., subjectAssertion has exactly one
         since saying 0..* is just too darn loose for type-safety


Darren Platt: Would separate "attribute languages" have their own
namespace? Dave: Yes. Participating organizations would agree upon a
common attribute language.

Prateek: We might want to come up with some SAML-specific attribute
vocabulary. Dave: Yes.

Phil: Doesn't think there will be applications in which a "full
extension schema" will be necessary. Feels that 70% of the requirements
can be specified using URI's. The use of XML Schema "<any>" is too much
of a wildcard. Bob Blakley: Is the concern that the receiver will not
be able to parse the query.

Bob Blakley: By open-ended Attribute Assertions are you thinking of
strings, name-value pairs, etc. Dave: XML documents.

General discussion about the concept of Attribute vocabularies. Keberos
attribute vocabularies, Windows domain attribute vocabularies, etc.
Notion of "schema registries" for registering these
vocabularies/schemas so you can say "If you are going to provide
Kerberos attributes you must use the following schema."

BobB:  profiling attribute types is one way of specifying schema

Dave:  Likes the idea of the attribute schema registry

Phill:  Two basic types of attributes - Boolean, set of tag value or
tag with a structured value pair.  In the first case, a very simple
query - has Alice got the release nuclear weapons permission?  Binary
attribute -either you have it or not, then there are the continuous
functions i.e. credit limit.  If you allow for the URI case, you can
clean up a large number of pieces in the standard.


Jeff: Shouldn't "authorizations are defined by SAML" more properly be
phrased "authorization decisions are defined by SAML". Dave: No. We
need not only a way to constrain the way in which authorization
decisions are represented, but we also need a way to constrain the
kinds of questions that can be asked. 


w.r.t. "authorization assertion" [as opposed to an "authz decision
assertion". ed.], Eve said: 

  authz assertion is still not agreed to [it's the 4th assertion type
                                          on the  proverbial table,
					  ed.]
  might be just part of decision-request
    i.e. "please give me answer about subject with these permissions"

  might be just part of decision-response
    i.e. "Yes, and subject has these permissions"



=================
Lunch & Breakouts
=================

Commercial web browser SAML profile - Prateek Mishra

[see section 3.1 of draft-sstc-bindings-model-04 ed.]

scenario is the local-nav-site-first thing
  where "handle service" is "inter-site transfer service"
design a reference-like "elementary artifact"
dest uses artifact to get real authn assertion
nature of "one-use"
  this is basically advice to relying parties:
    don't expect to replay this securely
proposed "artifact"
  has a type code, so could define others
  has a pointer to real assertionID, via "partner ID" and
    assertion ID
  "partnerID", 32 bits, identifying issuer
  "assertionID", meaning artifact handle, 64 bits
  specifically unsigned
artifact handle must be unguessable, this prevents forgery
note assertion could be attr assertion
what about protection against abuse by destination?
  well, issuer knows who destination was supposed to be
    so can reject query for that handle from bogus dest
    because query from dest must be authenticated





==================================
Afternoon sessions (Mon 25-Jun PM)
==================================


Authentication Assertion discussion, boardwork by Bob Blakley
-------------------------------------------------------------
[the group elected to consider authentication assertions first. ed.]


Please refer to Sections 1 and 2 of...

  "SSTC F2F #3 -- Whiteboard transcription" (aka "WhbTrnscp")
 
http://www.oasis-open.org/committees/security/minutes/SSTC-F2F-3-Notes-Hodges-WhiteboardTranscription-01.pdf
  (which is attached in the email message version of this document)

...for the "notes from the whiteboard" describing the structure of an
Assertion's "Basic Info" (aka "Header"; see Sec. 1 of WhbTrnscp), and
for the structure of of an Authentication Assertion and related
request/response messages (see Sec. 2 of WhbTrnscp). 


In the below notes, the following contractions are used..

  "AuthnAssn"	= "Authentication Assertions"
  "AuthnAssnReq"	= "AuthnAssn Request"
  "AuthnAssnResp"	= "AuthnAssn Response"



I. Points we had (rough) consensus on wrt AuthnAssn, AuthnAssnReq, &
   AuthnAssnResp

Points we had (rough) consensus on (as expressed by acclimation or
straw polls) in the context of AuthnAssn themselves, and
Requests/Response messages for/about them..

  1.0 AuthnAssn's overall structure and content, as noted in [sec 2.0
      of WhbTrnscp], except for the items that are marked with bold "?"s.
      Those still-under-discussion items nominally are..

	 <ipaddr>
	 <dns domain>
	 holder of key ("authenticator")

      These issues are further discussed, and specific issues raised,
      in the "II. Discussion and Issues..." section, below.


  2.0 The types of queries/requests we need to make for AuthnAssn. See
      [sec 2.1 of WhbTrnscp] and below. 

      (1) Return (#) unexpired authn assertions for "this" subject. 
          [via authntype (#)?]

      (2) Return the authn assertion with assnid (#).

      Issues that we don't seem to have resolved are nominally..

      Are there qualifications for "unexpired authn assertions" in (1)?
      e.g. a return a list of 'em? Are they supposed to be valid?

      Is there an implied or explicit Audience restriction upon query (1)?

      These issues are further discussed, and specific issues raised, in
      the "II. Discussion and Issues..." section, below.


  3.0 AuthnAssnReq's overall structure and content, as noted in [sec
      2.2 of WhbTrnscp], except for the items that are marked with bold
      "?"s and/or bold callouts. Those still-under-discussion items
      nominally are..

	 In the subject specifier..
	   Security domain in which name authenticated
	   holder of key ("authenticator")

	 In the AuthnAssnReq body proper..
	   assnid 
             syntax
             relation to issuer?
             > 1 allowed in AuthnAssnReq?

      These issues are further discussed, and specific issues raised, in
      the "II. Discussion and Issues..." section, below.


  4.0 AuthnType is composed of a "string". [sec 2.0, 2.1, & 2.2 of
      WhbTrnscp]

    4.1 There is (i.e. needs to be) some registry for AuthnTypes.
	[JeffH has proposed "the IANA" http://www.iana.org/ as a distinct
	possibility. ed.]

    4.2 In a AuthnAssnReq, one may specify a single AuthnType or "all
        AuthnTypes". [sec 2.2 of WhbTrnscp]


  5.0 AuthnAssnResp's  overall structure and content, as noted in [sec
      2.3 of WhbTrnscp]. No issues, nominally.


  6.0 The structure of "Basic Info, Conditions, & Advice". [sec 1.0 of
      WhbTrnscp], except for the items that are marked with bold "?"s and/or
      bold callouts. Those still-under-discussion items nominally are..

         we need to re-work the design of conditions.
    
         we need to have a careful, well-thought-out rationale and a
	 design for a "general conditions framework" before being able
	 to decide whether to include such in the specification.

     These issues are further discussed, and specific issues raised, in
     the "II. Discussion and Issues..." section, below.




II. Discussion and ISSUES wrt AuthnAssn, AuthnAssnReq, & AuthnAssnResp

Identifiers in various guises were topics of much discussion. The
nominal list of those types of identifiers that were discussed in this
AuthnAssn & AuthnAssnReq context were..

  AuthnType
  AssertionID
  Subject
  security domain

Details about AuthnType were largely agreed to and decided. See point
I.4.0 above. 

AssertionID engendered a fair bit of discussion. In any case consensus
was that we need them (see point I.3.0 above), but there's a fair bit
of disagreement over their composition. However, readers should note
that there is in-depth analysis and suggested resolutions on the list
about this. See [F1] below. 

ISSUE:[F2F#3-8]: We need to decide the syntax of AssertionID.

In general, as the discussion progressed, whenever we brought up
another item that ought to be an argument/parameter in an AuthnAssnReq,
we entered into a discussion about the syntax of the item. This lead
BobB to write the following list on the whiteboard..

  the "church of identifier syntax"
    URI, string, OID, type/value pairs, XML doc, DNS domain name, other?


We discussed various aspects of "subjects" and "subject specifiers". A
key question turned out to be..

  How do we identify a subject? 

We ended up with something that looks like (see [sec. 2.0 of WhbTrnscp])..

  security domain in which name was authenticated, and a subject name

  ..or..

  bearer, and holderofkey("authenticator"?)

However, there was significant pushback on the use of the term
"authenticator" here and in core-09.

ISSUE:[F2F#3-9]: what's the composition of a subject or "subject
specifier" within..
    an AuthnAssn?
    an AuthnAssnReq?
  Note that we have consensus on the overall composition as noted in 
  [sec. 2, 3, & 4 of WhbTrnscp]


ISSUE:[F2F#3-10]: we need to come up with a term other than
"authenticator" for holderOfKey.


In relation to subjects, we discussed what does "security domain" (aka
"namespace") identifiers look like? What is their syntax? What do they
designate? Are they arbitrary or are they structured? JeffH suggested
that they are essentially the same as Issuer identifiers. [there's a
concrete proposal on the table for Issuer identifiers to be DNS domain
names; see [F1] ed.]

ISSUE:[F2F#3-11]: what's the composition of a "security domain"
identifier? 


We discussed details of subject specifiers within an AuthnAssn, see
[sec. 2.0 of WhbTrnscp]. There was a fair bit of discussion about
so-called "advisory" information, which boiled down to the innermost
structure containing <ipaddr> and <dns domain> components. The key
comment about <ipaddr> was: "Even if it is essentially useless, many
deployers demand it (for whatever reasons), so you can't live without
it". 

ISSUE:[F2F#3-12]: Do we want "ipaddr" to optionally appear in an
AuthnAssn? 

ISSUE:[F2F#3-13]: Do we want a separate-from-the-subject-specifier,
optional, mention of DNS domain in an AuthnAssn? What are the semantics
for this and how are they different from the likely occurrence of a DNS
domain name in the Subject specifier proper? 

ISSUE:[F2F#3-14]: What's the role of "holderofkey("authenticator"?)" in
the AuthnAssn Subject specifier? Do we need it?


A couple of other issues came up in the course of the above discussion..

ISSUE:[F2F#3-15]: An Authn authority could issue assertions "for"
("from") multiple domains?

ISSUE:[F2F#3-16]: multiple Authn authorities could issue assertions
"for" a given single domain?


Then we entered into to a general discussion of "conditions and
advice", which turned into a discussion of the "Basic Info, Conditions,
& Advice" (aka "Header"), see [sec. 1 of WhbTrnscp]. This collection of
stuff nominally looks like this..

  Header
    Basic Info
      Version
      AssertionID
      Issuer
      Issue Instant
        NotBefore
        NotOnOrAfter
    Conditions
      Audience
    Advice
  
This discussion touched upon how best to ensure all of..

  extensibility to meet lots of requirements
  interoperability among implementations and deployments

Some observed that "audience" is the poster child for conditions. 

Some observed that we should separate the "must understand" semantic
from extensibility. 

There was a proposal to move "audience" up to a first-class element,
i.e. into Basic Info. See the ISSUES below. 


[There was some discussion of Conditions as an extensibility mechanism.
None of the notes-takers seemed to capture that particular thread. ed.]

There was another proposal to eliminate "extensible conditions" in
favor of adding specific conditions as first-class elements of the
general assertion [does this actually mean adding them to "Basic Info"?
ed.]. We need this in order to address issues of forward compatibility.

We took a few straw polls to see what we could decide on. We decided
that..

   Yes, we want something with the semantic of "conditions" to appear in 
   Assertions.

   Yes, we need to re-work the design of conditions. 

   Yes, we want to place the validity interval into the conditions
      However, it was noted that doesn't this make validity interval
      optional? Do we want that?

   "Maybe" to providing a general conditions framework

   "Maybe" to putting audiences into conditions


ISSUE:[F2F#3-17]: we need to re-work the design of conditions. The
design should provide rationale for placing, or not placing, the
validity interval and/or audiences within conditions. 

ISSUE:[F2F#3-18]: In order to decide whether to include a "general
conditions framework" [does this imply the so-called notions of
"extensibility"? ed.] in the overall design, we need to have a careful,
well-thought-out rationale and a design.



[F1] Present on-the-list discussion of Assertion Identifiers (AssertionIDs),
----------------------------------------------------------------------------
Issuer identifiers, and identifiers-in-general
----------------------------------------------

Initial messages beginning two threads on the list about AssertionIDs
and Issuer IDs...

  composition of AssertionID (Issue: DS-4-04: URIs for Assertion IDs) 
  http://lists.oasis-open.org/archives/security-services/200106/msg00025.html

  composition of Issuer identifier (also: "dns-date" URN NID) 
  http://lists.oasis-open.org/archives/security-services/200106/msg00082.html


Present summary messages in those threads...

  Re: composition of AssertionID (Issue: DS-4-04: URIs for Assertio nIDs) 
  http://lists.oasis-open.org/archives/security-services/200106/msg00158.html

  Re: composition of Issuer identifier (also: "dns-date" URN NID) 
  http://lists.oasis-open.org/archives/security-services/200106/msg00159.html


Overall thoughts on identifiers-in-general...

  URIs as general-purpose identifiers, and identifiers in general 
  http://lists.oasis-open.org/archives/security-services/200106/msg00074.html

[end of F1]




================================
           Next Day
================================
Morning Sessions (Tue 26-Jun AM)
================================


Attribute Assertion discussion, boardwork by Bob Blakley ( & Jeff Hodges)
-------------------------------------------------------------------------

Please refer to Section 3 of...

  "SSTC F2F #3 -- Whiteboard transcription" (aka "WhbTrnscp")
 
http://www.oasis-open.org/committees/security/minutes/SSTC-F2F-3-Notes-Hodges-WhiteboardTranscription-01.pdf
  (which is attached in the email message version of this document)

...for the "notes from the whiteboard" describing the structure of an
of an Attribute Assertion and related request/response messages. See
also section 1 of WhbTrnscp for description of an Assertion's "Basic
Info" (aka "Header").



In the below notes, the following contractions are used..

  "AttrAssn"		= "Attribute Assertions"
  "AttrAssnReq"		= "AttrAssn Request"
  "AttrAssnResp"	= "AttrAssn Response"




III. Points we had (rough) consensus on wrt AttrAssn, AttrAssnReq, &
     AttrAssnResp

Points we had (rough) consensus on (as expressed by acclimation or
straw polls) in the context of AttrAssn themselves, and
Requests/Response messages for/about them..


  1.0 AttrAssn's overall structure and content, as noted in [sec 3.0 of
      WhbTrnscp], except for the items that are marked with bold "?"s
      therein. Those still-under-discussion items nominally are..

         h.o.k. 	      -- "holder of key"
         			 no question mark, but circled in blue.
         assnid (assertion?)  -- within the subject specifier
         <xmlnamespace>       -- the angle brackets were in BROWN, but
         			 the xmlnamespace term itself wasn't.

      Additional issues noted in [sec 3.2 of WhbTrnscp] nominally are..

         What's the syntax of attr *values*? Are they monolithic opaque
         things, or do they have perceivable-in-protocol-context internal
         structure, and  if so, how do we refer to such?

      These issues are further discussed, and specific issues raised,
      in the "IV. Discussion and Issues..." section, below.

    1.1 A single AttrAssn may contain multiple attributes.

      1.1.1 Given a set of attributes that apply to a Subject and a set
	    of Attribute Assertion "buckets", it makes no semantic
	    difference how you divide the attributes among the buckets.
	    I.e...

        {A, B} is the same as {A}, {B}; 
          -- where "{X}" denotes the attr X embedded in an AttrAssn, and
             "{X, Y}" denotes the attrs X and Y embedded in an AttrAssn.

    1.2 The only Subjects of Attribute Assertions are Subjects as
        described by Authentication Assertions.


  2.0 The overall set of queries/requests we need to make for
      AttrAssns. See [sec 3.1 of WhbTrnscp]. The set of AttrAssnReqs,
      with all agreed-to refinements folded-in, nominally is..

   (1) Return a set of AttrAssns containing all the attrs for the subject (#).
   (2) Return *only* (ANY | ALL) following attributes (#) for the subject (#).
   (3) Return the Attribute Assertion with Assertion ID (#).
   (4) Return *only* the names of the attributes of the following subject (#).

      There are these nominal issues..

	 AttrAssnReqs (1) and (2) are largely similar (need to combine
	   them into  one request?)
	 AttrAssnReq (2) contains the qualifier (ANY | ALL), is it needed?
	 A use case is solicited for AttrAssnReq (4).

      These issues are further discussed, and specific issues raised,
      in the "IV. Discussion and Issues..." section, below.


  3.0 AttrAssnReq's overall structure and content, as noted in 
      [sec 3.2 of WhbTrnscp], except for the items that are marked with 
      bold "?"s and/or bold callouts. Those still-under-discussion items 
      nominally are..

	 Do we include an (ANY|ALL) qualifier in the request?
	 Are multiple assnid's (AssertionID) permissible in request?
	 "holder of key ("auth'r")" in the subject specifier is circled 
	 in blue.
	 Can we make use of XPath [F2] in describing attributes?

      These issues are further discussed, and specific issues raised,
      in the "IV. Discussion and Issues..." section, below.


  4.0 AttrAssnResp's overall structure and content, as noted in [sec
      3.3 of WhbTrnscp]. One issue is whether there is any indication of
      whether absolutely ALL of a subject's attrs were returned to the
      requester when ALL were explicitly requested. This issue is further
      discussed, and specific issues raised, in the "IV. Discussion and
      Issues..." section, below.


  5.0 We agreed to use the term "security domain" instead of
      "namespace" in all discussions of Subjects and Subject Specifiers.
      This was retroactively applied to all material on the whiteboard.
      This result is represented in [WhbTrnscp].



IV. Discussion and ISSUES wrt AttrAssn, AttrAssnReq, & AttrAssnResp

Discussion began with Hal raising this point..

  Hal: Do we want to leave the possibility open to identify Subjects by
       a reference to another assertion? General discussion. Irving
       Reid: For example, when Attribute Assertions are attached to
       Session Assertions and not Principals. Leave as open issue.

ISSUE:[F2F#3-19]: can you designate a subject using assertion ID?


Then we entered discussion of the sorts AttrAssnReqs we need. The four
types we ended up with on the whiteboard nominally are (from Gil's
notes (i.e. unrefined. cf. III.2.0 above) )...

(1) Give me a set of Attribute Assertion containing all the attributes 
    for the subject (#).
(2) Give me (ANY | ALL) following attributes (#) for the subject (#). 
    (not other?)
(3) Return the Attribute Assertion with Assertion ID (#).
(4) Give me the names of the attributes the following subject (#) has, 
    but not their values.

[cf. [sec 3.1 of WhbTrnscp], ed.]

In AttrAssnReq (2), we didn't have consensus on the inclusion of the
"(ANY | ALL)" qualifier.

ISSUE:[F2F#3-20]: Is "(ANY | ALL)" qualifier to be included in
AttrAssnReq (2), or whatever AttrAssnReq (2) morphs into (see next
ISSUE). 

[AttrAssnReq (1) and (2) are only subtlety different. Can needs be met
with a single request? Is the rationale for AttrAssnReq (1) being
distinct from (2), and for AttrAssnReq (1) having "a set of AttrAssn's"
as a qualifier, that in this way an AttrAuthority may return a set of
attrs from disparate security domains?  ed.]

ISSUE:[F2F#3-21]: Is it feasible to meet the needs implied by queries
(1) and (2) with one request? If not we need to carefully note the
rationale for having the two distinct forms of request. 


ISSUE:[F2F#3-22]: Do we want to support AttrAssnReqs about the
attribute schema?

ISSUE:[F2F#3-23]: AttrAssnReq (4) is intended to return attr names
only. Is there a use case to support this?


General discussion about the behavior of the Attribute Authority under
conditions in which it doesn't return "all" of the attributes it knows
about. This is the discussion wherein the "(ANY | ALL)" qualifier used
in AttrAssnReq (2) arose. The proposed semantics are..

    o	"any" - return all the attributes you are allowed to give me. I
don't care if there are some you can't or are not allowed to give me.

    o	 "all" - return all the attributes you are allowed to give me.
Provide an error code that states "there are some attributes I couldn't
give you".

There was a fair bit of discussion about the semantics of "ALL" -- is
it necessary to support "all or error" kind of request?

ISSUE:[F2F#3-24]: What should the semantics of AttrAssnReq (2) be?
Should an Attr Authority who cannot/willnot return ALL the attrs it
knows of for a given subject indicate such in the AttrAssnResp message?


There was some discussion about whether, with respect to AttrAssnReq
(2), in it's postulated explicitly-enumerated-attributes form, whether
the requester can ask about multiple attributes in a single request.
Some folks felt that it would make error handling tough(er). 

ISSUE:[F2F#3-25]: can a requester request an explicitly enumerated list
of attributes using AttrAssnReq (2)? Some people are asserting that
this will "make a mess of error handling".

[ An arguably common attribute authority implementation will be one
layered over an LDAP-based directory service. The LDAP-based directory
semantics presented to such an attribute authority are noted in [F3],
below. Multiple attrs, of an entry, may be requested in a given LDAP
search/read request. Note that there are no errors returned about
whether or not specific attributes were found in the entry or not; LDAP
does return errors about whether the entry itself was found, or not. If
SAML mandates that the Attr Authority MUST return errors about each
individually requested attribute, then that will make layering an Attr
Authority over an LDAP-based directory arguably harder. One approach
would be to store each individual attribute of a subject in an
individual directory entry subordinate to an entry representing the
subject. Whether forcing such a design on Attr Authority
designers/implementors/deployers is reasonable or not is debatable.
ed.]



Irving Reid had a question about AttrAssns in terms of whether they can
"refer" only to subjects, can they refer to other things such as
Session Assertions?

Bob Blakley responded that an Attribute Authority can only issue
Assertions about things it knows about. How does it know about
sessions?

We discussed Subjects and Principals wrt AttrAssns, took a straw poll,
and decided that..

o	Yes, the only Subjects of Attribute Assertions are Subjects as
described by Authentication Assertions.

[does this mean we decided that the subject specifiers of AttrAssns are
the same structure-wise (i.e. syntactically) as subject specifiers in
AuthnAssns, OR does it mean that a given instance of an AttrAssn must
contain a Subject specifier value that is the same as the Subject
specifier in some instance of an AuthnAssn? The editor thinks it is the
former, but it isn't clear from the raw notes. ed.]

ISSUE:[F2F#3-26]: this statement's exact meaning needs to be clarified:
"the only Subjects of Attribute Assertions are Subjects as described by
Authentication Assertions."


There was general discussion on the advisability of including either
Assertion ID or Assertion in the Subject of an Attribute Assertion. No
consensus reached.

ISSUE:[F2F#3-27]: should the design of the subject specifier for
AttrAssns include provision for the subject specifiers value being an
AssertionID or an (AuthnAssn) Assertion?


There was general discussion about the attrs themselves specified by a
requester in AttrAssnReq (2)

Hal was in favor of supplying enumerated lists in AttrAssnReq (2), but
if we add contexts, profiles, etc. then things get really messy.

Irving suggested SAML 1.0 could be successful with simple enumerated
lists. Attribute names should be a simple, unique blob.

Hal claimed attributes should be issuer and domain/namespace relative.
Agrees with Irving that Attribute names should be simple, unique blobs.

Simon wondered how do we support cross-domain systems with multiple
domains/namespaces?

General discussion ensued on the scope of Attribute Names. Scoped
implicitly by the namespace of the Subject in the Authz Attribute, or
scoped explicitly in the Attribute Name?

We followed a tangent and discussed the difference between "namespaces"
and "domains" and noted that namespaces and domains frequently overlap.

We agreed to replace all occurrences of "namespace" with "security
domain" in Subjects and Subject Specifiers in all the material on the
whiteboard. See III.5.0 above and [WhbTrnscp].


Returning to the discussion of attr names, we wondered about the
"namespace" of an Attribute Name?

Irving noted that the "xmlnamespace" that applies to an Attribute Name
specifies the schema of the Attribute Value. That Attribute Value may
or may not be Security Domain relative. If the Attribute Value is
Security Domain relative, it is up to the Entities that produce and
consume these types of Attributes to agree on the semantics of the
Security Domain.

We agreed that when a requester asks for explicit Attributes, which are
scoped by xmlnamespace, it is illegal for the Attribute Authority to
return Attributes other than the one's specified by the requester. See
III.2.0.(2) above, and [sec 3.1 of WhbTrnscp].

[This seems to imply that we didn't nail down whether all attr names in
an AttrAssn MUST be xmlnamespace-qualified. Hence the angle brackets
shown surrounding "<xmlnamespace>" in the body of an AttrAssn in [sec.
3.0 of WhbTrnscp] are indeed legitimate. This raises an ISSUE. ed.]

ISSUE:[F2F#3-37]: Must all attr names in the body  of an AttrAssn be
qualified by xmlname space?


General discussion ensued about the complexity of attribute values and
attribute names.

   o  One possible approach is to use XPath [F2] in AttrAssnReqs.

   o  Other approach is to define a very simple name/value pairs. A
      problem with this is that, if the users/developers want to formulate
      any kind of structured values, they have to flatten them into the
      SAML-defined thing. Thus the concern is how do we allow for flexible
      [i.e. complex, ed.] value structures without unduly complicating
      AttrAssnReqs & AttrAssnResps?

ISSUE:[F2F#3-28]: The precise overall syntax of attr values needs to be
decided (see III.1.0) Nominally, an attr value should be one of..
  1. just a monolithic opaque thing, with any internal syntax agreed to
     out-of-band.
  2. something with perceivable-in-protocol-context internal structure


ISSUE:[F2F#3-29]: Does the use of XPath [F2] in AttrAssnReqs mitigate
the restrictiveness of having attr values being monolithic opaque
things, presumably where the value is actually XML encoded and having
arbitrarily complexity?




[F2] XPath reference...
-----------------------
XML Path Language (XPath)
Version 1.0
W3C Recommendation 16 November 1999
http://www.w3.org/TR/xpath
------------------------



[F3] nuances of LDAPv3 responses wrt attributes
-----------------------------------------------
>From http://www.ietf.org/rfc/rfc2251.txt, section 4.5.1, pages 25 & 26...

        SearchRequest ::= [APPLICATION 3] SEQUENCE {
                baseObject      LDAPDN,
                scope           ENUMERATED {
                        baseObject              (0),
                        singleLevel             (1),
                        wholeSubtree            (2) },
                derefAliases    ENUMERATED {
                        neverDerefAliases       (0),
                        derefInSearching        (1),
                        derefFindingBaseObj     (2),
                        derefAlways             (3) },
                sizeLimit       INTEGER (0 .. maxInt),
                timeLimit       INTEGER (0 .. maxInt),
                typesOnly       BOOLEAN,
                filter          Filter,
                attributes      AttributeDescriptionList }
                    ^                       ^
                    +-----------------------+
            This is where the client specifies the list of attrs to return
            from each directory entry that matches the baseobject and/or 
            filter.

>From rfc2251, section 4.5.1, pages 29...

   - attributes: A list of the attributes to be returned from each entry
     which matches the search filter. There are two special values which
     may be used: an empty list with no attributes, and the attribute
     description string "*".  Both of these signify that all user
     attributes are to be returned.  (The "*" allows the client to
     request all user attributes in addition to specific operational
     attributes).

     Attributes MUST be named at most once in the list, and are returned
     at most once in an entry.   If there are attribute descriptions in
     the list which are not recognized, they are ignored by the server.

     If the client does not want any attributes returned, it can specify
     a list containing only the attribute with OID "1.1".  This OID was
     chosen arbitrarily and does not correspond to any attribute in use.

     Client implementors should note that even if all user attributes are
     requested, some attributes of the entry may not be included in
     search results due to access control or other restrictions.
     Furthermore, servers will not return operational attributes, such
     as objectClasses or attributeTypes, unless they are listed by name,
     since there may be extremely large number of values for certain
     operational attributes. (A list of operational attributes for use
     in LDAP is given in [5].)

-----------------------------------------------
[end of F3]


=================
Lunch & Breakouts
=================

<no breakouts were described in notes-takers' notes>


==================================
Afternoon Sessions (Tue 26-Jun PM)
==================================


Authorization Decision Assertion discussion, boardwork by Bob Blakley
---------------------------------------------------------------------


Please refer to Section 4 of...

  "SSTC F2F #3 -- Whiteboard transcription" (aka "WhbTrnscp")
 
http://www.oasis-open.org/committees/security/minutes/SSTC-F2F-3-Notes-Hodges-WhiteboardTranscription-01.pdf
  (which is attached in the email message version of this document)

...for the "notes from the whiteboard" describing the structure of an
of an  Authorization Decision Assertion and related request/response
messages. See also section 1 of WhbTrnscp for description of an
Assertion's "Basic Info" (aka "Header").



In the below notes, the following contractions are used..

  "AuthzDecAssn"	= "Authorization Decision Assertion"
  "AuthzDecAssnReq"	= "AuthzDecAssn Request"
  "AuthzDecAssnResp"	= "AuthzDecAssn Response"



V. Points we had (rough) consensus on wrt AuthzDecAssn,
   AuthzDecAssnReq, & AuthzDecAssnResp

Points we had (rough) consensus on (as expressed by acclimation or
straw polls) in the context of AuthzDecAssn themselves, and
Requests/Response messages for/about them..


  1.0 AuthzDecAssn's overall structure and content, as noted in [sec
      4.0 of WhbTrnscp], except for the items that are marked with bold
      "?"s and/or bold callouts. Those still-under-discussion items
      nominally are..

         (assnid/assertion)*          -- in the subject specifier

      These issues are further discussed, and specific issues raised,
      in the "VI. Discussion and Issues..." section, below.


  2.0 The type of query/request we need to make for AuthzDecAssn. See
      [sec 4.1 of WhbTrnscp].

       (1) should operation Y on resource Z be allowed, given evidence E
           (including subject & optionally subject assertions)

      Issues raised about this nominally are..

         Must the "subject" and the "subject assertions" of the phrase
         "including subject & optionally subject assertions" from (1)
         all refer to the same subject, or may they refer to different
	 subjects?

         What are the semantics of including assnids or assertions in the
         subject specifier as well as in the AuthzDecAssn body? 

      These issues are further discussed, and specific issues raised,
      in the "VI. Discussion and Issues..." section, below.


  3.0 AuthzDecAssnReq's overall structure and content, as noted in [sec
      4.2 of WhbTrnscp], except for the items that are marked with bold
      "?"s and/or bold callouts. Those still-under-discussion items
      nominally are..

         Must the "subject", in the subject specifier, and the "subject
         assertions" in an AuthzDecReq body, all refer to the same
         subject, or may they refer to different subjects?

         How do we go about defining and sharing "actions"? Define and
         rely upon a registry of namespaces?

         An AuthzDecAssnReq may simply refer to another assn by assnid,
         what are the semantics of referring to multiple assertions?

      These issues are further discussed, and specific issues raised, in
      the "VI. Discussion and Issues..." section, below.


  4.0 AuthzDecAssnResp's overall structure and content, as noted in . 
      No issues, nominally.





VI. Discussion and ISSUES wrt AuthzDecAssn, AuthzDecAssnReq, &
    AuthzDecAssnResp


Discussion ensued about the type of AuthzDec query we need to make. The
answer converged quickly to only(see [sec 4.1 & 4.2 of WhbTrnscp])...

           should operation Y on resource Z be allowed, given evidence E
           (including subject & optionally subject assertions)
           [see V.2.0.(1), above]

..and quickly dove into what an AuthzDecAssnReq looks like. 

Jeff: Given that our Authorization Request allows the requester to
specify a collection of assertions, does the Subject of all of these
assertions have to be "the same"?

Examples of why a collection of assertions provided to an Authorization
request may refer to multiple Subjects

   1.	RLBob's example (directly quoted from his notes):
       
         it would be useful to include:
           attr assertion saying
             issuer of attr assertion A on the main subject has attribute
               "really good issuer"



Carlisle: The PEP is stupid. The PDP is smart. How can the stupid PEP
tell if all the Assertions are about the same Subject?

Simon: How can we have a multiplicity of Subjects? Up until now we've
always been dealing with a single Subject. How come the PEP is suddenly
dealing with all these Subjects?

ISSUE:[F2F#3-30]: Must the "subject" and the "subject assertions" of
the phrase "including subject & optionally subject assertions" from
V.2.0.(1) all refer to the same subject, or may they refer to different
subjects?

ISSUE:[F2F#3-31]: What are the semantics of including assnids or
assertions in the subject specifier as well as in the AuthzDecAssn
body? 


Discussion ensued over the use of the term "permission" in one of our
draft docs (core-09?) in the nominally same overall context as
AuthzDecAssn's and AuthzDecAssn{Req,Resp}'s. 

Hal: Prefers "operator" and "action" to "permission"
Darren: Agrees that the term "permission" sucks.

There was rough consensus to use the terms "object" and "action" in
AuthzDecAssn's and AuthzDecAssn{Req,Resp}. E.g..

  The subject is requesting to perform an "action" on this "object".


Discussion ensued about the syntax of actions and objects..

Evan: an action is a string, possibly scoped with a namespace
identifier and an object is a string, possibly scoped with a namespace
identifier.

Phil: advocates the use of URI's for both the action and the object

David Orchard & JeffH: advocate URI's for objects but not for actions

There was rough consensus that actions need to be qualified by some
sort of "namespace". 

[plausible examples being, borrowing from RLBob's notes..

  xmlns:file-action-namespace
    where elements (or attributes?) defined in this namespace are..
      read,write,append,delete,etc.
  
  xmlns:http-action-namespace
    where elements (or attributes?) defined in this namespace are..
      GET,POST,etc.

ed.]

ISSUE:[F2F#3-32]: should there be a registry of action namespaces?
Presumably, the set of actions defined in each namespace is defined,
within such a registry. 


Discussion ensued about the AuthzDecAssn itself (see [sec. 4.0 of
WhbTrnscp])...

There was rough consensus that the answer to the authorization decision
request must lie within the AuthzDecAssn.

Simon: can we add additional parameters to the Authorization Request
that asks the PDP for extra, advice-type info? Bob: SAML 1.0 can be
successful without this feature. There was rough consensus agreeing
with Bob. 

David O: W/respect to Tim Moses' "advice" such as "No, if you had been
authenticated via X.509 I might have let you" are we going to support
this? Is "advice" an assertion? [this question asking whether we
want/intend to include the notion of the PDP returning "advice" within
it's AuthzDecAssnResp, as is presently nominally done in core-09
(correct?). ed.]

ISSUE:[F2F#3-33]: Are we including the capability to include "advice"
within AuthzDecAssns and thus AuthzDecAssnResps?

ISSUE:[F2F#3-34]: What's "advice"? What's the semantics? How's it
represented? These questions (and more) need to be answered if the
answer to the previous Issue is "yes".


Discussion ensued about whether all the stuff in an AuthzDecAssn (i.e.
the input subject specifier, subject assertions, object, and action)
are also placed there when the authz answer is "no"? 

The rough consensus answer to this question was "yes". It was noted by
someone that it's very important from a security perspective for the
meaning of the message, an AuthzDecAssn in this case, to be clear from
the content of the message itself. 

The answer to this question is represented by the whiteboard description
of the AuthzDecAssnResp in [sec. 4.3 of WhbTrnscp].


================================
Global comments, asides, musings
================================


ISSUE:[F2F#3-35]: BobB said in an aside that there is something wrong
with at least some of the occurrences of our use of the "bearer" in
Subject specifiers in all of the above constructs. Need to get him to
elaborate in detail on what his observations are.

>From the brief mention of req/resp protocol and schema in the Clossing
Discussion...

Evan: Would it be advantageous to specify one schema for the core
assertions and another schema for the request/response protocol?

-  What are the advantages and drawbacks?
-  Request/response could reference core assertions.

-  There could be many schemas that reference the core assertions
   without referencing the request/response stuff. Making them pull in
   the request/response stuff is just extra overhead.

ISSUE:[F2F#3-36]: Should we design the schema for Assertions and their
respective request/response messages in different XML namespaces?



=========================================================================
Closing Discussion of Schedule Outlook, work signups, meeting dates, etc.
=========================================================================

VII. Points we had (rough) consensus on wrt Schedule Outlook, work
     signups, meeting dates, etc.

  1.0 The group noted that we (the SSTC) did not in fact generate a
"committee specification" for SAML, nor hand such off to OASIS
administration for review, by 1-Jun-2001. I.e. "we (SSTC) are
'slipping'" with respect to the schedule we set for ourselves in early
2001.

  2.0 Phill Hallam-Baker, David Orchard, and Prateek Mishra (plus
perhaps designee's) will merge the information about Assertions and
their respective Request/Response messages captured in this minutes
document, plus [WhbTrnscp] plus assertions-00, and cast it into a
document using core-09 as a base document style- and text-wise.

  3.0 Having a "stable" SAML specification by 1-Dec-2001. The
connotations here are that the schema and protocol messages won't be
changing by large amounts each time we crack open the docs and discuss
them. That said, these docs would not be "polished" to the point of
being submittable to OASIS at-large for approval as a OASIS standard. 

  4.0 Having "sample" SAML-based implementations that can either or
both be tested together (e.g. at a "connect-a-thon"-style event (e.g.
DirConnect)), and/or distributed freely (in either source or binary
form). Having folks both inside and outside of the immediate SSTC/SAML
community trying out and experimenting with actual code is a key factor
to long-term success. Witness HTTP/HTML, LDAP, and others. However, we
did not get any firm commitments at this time to produce such "sample"
implementations.

  5.0 The goal for submission to OASIS administration as a candidate
OASIS standard is 1-Mar-2002. 


[IMPORTANT NOTE: 2.0, 3.0, and 4.0 embody "first order" goals. The
rough consensus was that if we can attain these goals, then our
likelihood of success will be higher. Success is defined as having
demonstrable, multi-vendor SAML-based interoperability, available in
off-the-shelf products, and such products actively being used in
commercial deployments. ed.]



VIII. Discussion and ISSUES wrt Schedule Outlook, work signups, meeting
      dates, etc.

Discussion ensued on how to proceed with incorporating all this
wonderful rough consensus into our draft specification document(s)...

Jeff: Next steps and scheduling. Take substantive discussion to the
list. 

In these notes [meaning the stuff on the whiteboard and captured in the
notes-taker's notes], red and brown items should be considered for
addition to the issues list.

Hal: Err on the side of inclusion for the issues list.

Prateek: Now we have a consensus proposal (on the white boards). How
does this relate to core-09 and the assertion-00 proposal?

Irving: The whiteboard stuff isn't a competing proposal, it's just
advice for modifying core-09 and assertion-00.

PHB: There is no competition between the whiteboard material and
core-09. It's difficult to write specification prose without nailing
down the schema.

Jeff: Someone needs to take these minutes, core-09, and assertion-00,
and come up with a schema that validates. We need to drive towards
getting the red items nailed down.

Hal: It would be productive for the unnamed sucker (from above) to
propose solutions to the red/brown stuff.

Jeff: Crux of the biscuit [note-taker's expression. ed.] is to sign-up
people to do the work of consolidating whiteboard stuff into a schema
and propose specification text that accompanies it. Proposal on the
floor is to build on core-09 text and document-format-wise. Dave O.
volunteers. Prateek can volunteer somebody. Decided:

-	Jeff will produce minutes of this meeting ASAP
-	PHB, David O, and Prateek will grind all the material together

[see VII.1.0 above]


PHB: In all the work done at F2F#3 supersedes Tim Moses' work on
protocols-00. core-10 [corrected from "PHB-0.91". ed.] will have an
extra section on request/response.



Discussion ensued about the SSTC overall schedule... 

Jeff: It was 2 months between F2F#2 and F2F#3. Considering how
productive F2F#3 was, maybe we could have one real soon?

PHB: Will need to have a F2F to discuss the protocol bindings and
profiles bit. We should have another assertion-oriented F2F before
then.

Jeff: Can we nail down the assertions without another F2F? We may need
two more F2F's; one for core assertions, one for bindings.

Darren: We're slipping! [see VII.2.0 above]

Jeff: How many people think we will have an independently
implementable, and subsequently *interoperable*, SAML specification by
Sept. 1? <dead silence>

PHB: Doesn't think it is likely that we will get a quorum meeting in
July or August.

Jeff: We will need a quorum to make the necessary major decisions.

Eve: We've already slipped the "beginning of June" date. It is possible
for us to slip one (1) quarter iff we are really diligent. Doesn't see
problem with not making quorum at next F2F because all the work will
get approved at the next TC conference call. August conference in
Montreal that we may be able to piggyback on (Thurs or Fri?)

Jeff: said he is on vacation second week of August and for nearly two
weeks in Sept.

Hal: Main problem is to schedule a meeting we could get to [i.e. "we
can get a majority of us at", ed.] without worrying about what we need
to talk about.

Jeff: Middle of August?

Eve: Should do an Evite poll?

Prateek: When the hell is our proposed date if we are going to miss
Sept 1?

Jeff: Eve is lobbying for Dec. 1.

Eve: We missed June 1, we should shoot for Sept. 1 <dead silence>.

PHB: How can we have a F2F in August then give the editors 2 weeks to
get everything right?

Eve: Proposes October 1st. One F2F in August, one F2F in Sept.

David Orchard: Doesn't think we will have a spec even on Dec 1. Work is
going slow. Haven't even got to the real nasty details. [there will be
the ] Pain of [likely necessary] major revisions.

Evan: Limited window of opportunity for SAML. After a while the point
will be moot. If we wait too long nobody will care.

PHB: Less interested in when the standard gets approved, compared to
when we can build prototypes and stage interop testing. Just interested
in shipping products. HTTP and HTML were in active use for years before
the specs were "nailed down"

Gil: We shouldn't keep re-adjusting the "done date".

Jeff: Who here can commit to providing an open reference
implementation? Implementations hit the street way before standard was
accepted. This helps the standard get accepted.

PHB: Verisign can't commit to shipping source code.

Jeff: Binary implementations are interesting. Source code is better
because people can tweak them as the spec progresses.

Carlilse: In order to have a reference implementation, don't we have to
have the conformance work done.

All: We don't need a "reference", we need a "sample" implementations. 

Jeff: A freely-available, Apache-SAML-PEP would be "very cool".

Charles: The sample PDP will probably be bolted onto a commercial
policy engine.

Prateek: This whole discussion is a completely separate subject. He is
not at the strategic level to be able to make these sorts of decisions.
Next meeting: one day protocols, one day bindings/profiles.

Jeff: Need to spend F2F time wrapping up assertions and
request/response. How long will this take? We can start talking about
bindings in a more concrete sense "very soon". Whether we can do both
at a F2F depends upon how much time the first consumes. 

Gil: Is the "two day" thing cast in stone?

Jeff: No. We could go longer if folks want. [Further discussion with
folks results with 3 days as seeming to be the longest we could
stand.] 

JeffH: Looks like two more F2F's. When?

We decided on shooting for mid-to-late Aug and end-Sept-to-beg-of-Oct. 


[We discussed all of the above a bit further. The general feeling in
the room was that we shouldn't slip with a low probability of keeping
to the newly adjusted schedule. We thought that we should slip such
that we have a much higher probability of keeping our dates. 

Thus we decided upon these goals [also duly noted in VII.3.0 - VII.5.0,
above]...

  1. Having a "stable" SAML specification by 1-Dec-2001. The
     connotations here are that the schema and protocol messages won't
     be changing by large amounts each time we crack open the docs and
     discuss them. That said, these docs would not be "polished" to the
     point of being submittable to OASIS at-large for approval as a
     OASIS standard.

    1.1 The goal for submission to OASIS administration as a candidate
        OASIS standard is 1-Mar-2002. 

  2. Having "sample" SAML-based implementations that can either or both
     be tested together (e.g. at a "connect-a-thon"-style event (e.g.
     DirConnect)), and/or distributed freely (in either source or binary
     form). Having folks both inside and outside of the immediate
     SSTC/SAML community trying out and experimenting with actual code
     is a key factor to long-term success. Witness HTTP/HTML, LDAP, and
     others. However, we did not get any firm commitments at this time
     to produce such "sample" implementations.

ed.]





===============
end of document
===============

SSTC-F2F-3-Notes-Hodges-WhiteboardTranscription-01.pdf



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC