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] | [List Home]


Subject: Agenda for today's con-call


Sorry for the delay in getting the agenda out…

 

Dial in info: +1 865 673 6950 #351-8396

  1. Review/Accept minutes from 22-June con-call meeting.  Link to minutes as updated by Steve A:
    1. http://lists.oasis-open.org/archives/security-services/200406/msg00091.html
  2. Document review.  Scott’s status message:
    1. http://lists.oasis-open.org/archives/security-services/200407/msg00017.html
  3. Schedule review.  We previously stated that today’s con-call would start “sort of a pre-last-call deadline for final input.  Depending on how well things come together, we might possibly start our TC last call here, but we opted to allow another week before doing that.”  The plan is to vote next week to start the 2 week TC last call period on 13-July.  The remainder of the schedule is:

·         July 6: All specification suite documents must have incorporated all input from the list and F2F #5. Note that this gives us 3 weeks since the F2F to complete all document changes and to resolve issues and action items.  This now begins sort of a pre-last-call deadline for final input.  Depending on how well things come together, we might possibly start our TC last call here, but we opted to allow another week before doing that.

·         July 13: VOTE to start 2-week committee last call period (includes external public review).

·         July 20: Review any last call input to date.

·         July 27: Cut-off date for TC last call input. All outstanding issues have been dealt with according to the last call process. The specs now become our "candidate” Committee Drafts and the TC addresses any outstanding non-normative editorial issues

·         August 3: VOTE to move spec’s to “Committee Draft” status (requires YES votes from 2/3 of ALL voting members). VOTE to move CD spec’s into 30-day Public Review for OASIS standardization (majority vote). Edit doc’s for CD status. Notify TC admin of the start of formal Public Review.

·         September 7 (first call following 30-day public review): Make sure all public review comments have been properly dispatched. Final editorial changes must be complete. VOTE to re-approve spec’s as final Committee Draft and VOTE to submit to OASIS for standardization. 

·         September 8-15: Complete all submission paperwork. All submissions for an October voting period must be complete by September 15.

  1. Action item review. [Apologies for the sorting order, but when sorting by open status, Kavi doesn’t use a secondary sort by AI number]

 

Report created 06 July 2004 10:58am EDT

 

#0164: Add doc text for profile, etc. submission process

Owner: Scott Cantor

Status: Open

Assigned: 22 Jun 2004

Due: ---

Comments:
Rob Philpott 2004-06-22 16:31 GMT
All documents will include text directing readers to the SSTC web site for information on the process for submitting new authn context classes, profile documents, etc.


#0175: Add Security Context to glossary

Owner: Jeff Hodges

Status: Open

Assigned: 23 Jun 2004

Due: ---

Comments:
Rob Philpott 2004-06-23 20:12 GMT
as discussed at F2F #5


#0173: Add XACML profile to profiles doc

Owner: Scott Cantor

Status: Open

Assigned: 23 Jun 2004

Due: ---

Comments:
Rob Philpott 2004-06-23 20:06 GMT
As discussed at F2F #5.


#0143: Check SAML schema for consistency

Owner: Eve Maler

Status: Open

Assigned: 29 Apr 2004

Due: ---

Comments:
Prateek Mishra 2004-04-29 21:49 GMT
*** Follow-up: Examine SAML schema for consistent use of XML attributes vs. elements


#0177: Clarify OneTimeUse description

Owner: Hal Lockhart

Status: Open

Assigned: 23 Jun 2004

Due: ---

Comments:
Rob Philpott 2004-06-23 20:15 GMT
As discussed at F2F #5:
Hal will look at OneTimeUse text again and attempt to clarify: in progress.


#0157: Define Binding and Profile in Glossary

Owner: Jeff Hodges

Status: Open

Assigned: 30 Apr 2004

Due: ---

Comments:
Prateek Mishra 2004-04-30 18:10 GMT
o "atomic unit of interoperability" proposed


#0174: Document values for DCE attribute names

Owner: Scott Cantor

Status: Open

Assigned: 23 Jun 2004

Due: ---

Comments:
Rob Philpott 2004-06-23 20:09 GMT
document the well-known values for the DCE attribute


#0169: Draft formal response to IBM research report on SAML

Owner: John Linn

Status: Open

Assigned: 22 Jun 2004

Due: ---

Comments:
Rob Philpott 2004-06-22 17:09 GMT
John Linn and Prateek agreed to draft a formal SSTC document commenting on, acknowledging, and clarifying certain points in the IBM Research Report RZ 3501 (# 99427) 06/30/03. The goal is to have this document approved as a Committee Draft.


#0144: Explain optional subject decision

Owner: Eve Maler

Status: Open

Assigned: 29 Apr 2004

Due: ---

Comments:
Prateek Mishra 2004-04-29 21:51 GMT
*** AI: Eve: Optional subject implemented in core spec prose. Schema shows that subject is optional.

o Eve: Has wanted to create a rationale for some of the decisions made on spec. Decision on subject less statements is a good example of what needs to be documented. Making an explicit design decision that is not really explicit on. By choosing to add prose to core spec we're making a stealth abstract profile (generic design decision) that applies to all explicit profiles.

o Scott: data model (design) decision to require subjects in all SAML statements.


#0166: Investigate use of Wiki from teh web site

Owner: Scott Cantor

Status: Open

Assigned: 22 Jun 2004

Due: ---

Comments:
Rob Philpott 2004-06-22 16:40 GMT
Scott will investigate the establishment of a wiki for SSTC use to be linked from the SSTC web site.


#0131: Migration document describing changes to subject in SAML 2.0

Owner: Jeff Hodges

Status: Open

Assigned: 13 Apr 2004

Due: ---

Comments:
Prateek Mishra 2004-04-13 04:31 GMT
Explain how treatment of subjects have changed in going from SAML 1.X
to SAML 2.0. This might be an action for Scott?


#0170: Move Authn Context Declarations to XML Schema-centric approach

Owner: John Kemp

Status: Open

Assigned: 23 Jun 2004

Due: ---

Comments:
Rob Philpott 2004-06-23 16:06 GMT
JohnK and Scott to move Authn Context Declarations to XML Schema-centric approach.


#0163: Need process for submission of profiles/authn context classes, etc.

Owner: Rob Philpott

Status: Open

Assigned: 22 Jun 2004

Due: ---

Comments:
Rob Philpott 2004-06-22 16:29 GMT
On the web site, we need to state what the process is for submitting and dealing with additional authn context classes, new profile documents, etc.

Rob Philpott 2004-06-23 16:03 GMT
Note that this is different from AI 164 for SCott and John K to propose text within the spec documents that points to the web site.


#0171: Need profile designator for stmt/query?

Owner: Scott Cantor

Status: Open

Assigned: 23 Jun 2004

Due: ---

Comments:
Rob Philpott 2004-06-23 20:02 GMT
Discussed at f2f #5:
- potentially allowing for endpoint metadata
- issue was whether NULL profile was needed, etc


#0172: need text for syntax of attr values in LDAP/X.500 profile

Owner: Bob Morgan

Status: Open

Assigned: 23 Jun 2004

Due: ---

Comments:
Rob Philpott 2004-06-23 20:05 GMT
Discussed at f2f#5:
RLBob to review & propose text for handling syntax of attr values in LDAP/X.500 profile.


#0123: Obtain MIME type registration for HTTP lookup of SAML

Owner: Jeff Hodges

Status: Open

Assigned: 13 Feb 2004

Due: ---

Comments:
Rob Philpott 2004-06-23 15:29 GMT
Attached is the initial rev of an I-D seeking to register the MIME media type
"application/saml+xml". Please review.

I've pinged the I-D editor to request a filename for the doc, I'll submit it to
both the I-D editor and the SSTC doc repository once that's finalized (std
procedure for I-Ds).

In concocting this draft, I've noted that MIME media type registrations aren't
necessarily the simple little registration exercise I'd thought they were. They
(the ietf-types@iana.org denizens) may desire more content, e.g. sec
considerations, in this doc. We'll see. Nominally, I think it's "good enough"
as is, especially since the SAML spec sets have thorough sec considerations
sections and I've referenced said spec sets carefully. Anyway, we'll see.

Also, I based this on a draft registration for application/rdf+xml. In that
draft, Aaron Schwartz claimed an optional parameter of "charset", and indicated
that the considerations thereof are the same as for "application/xml" (as
documented in http://www.ietf.org/rfc/rfc3023.txt). Additionally, he did the
same thing for the "encoding considerations", i.e. said they were the same as
for "application/xml". So, without excrutiating research, I did the same thing
in this draft. fwiw/fyi.

anyway, lemme know whatcha think.

thanks,

JeffH


#0158: Propose changes to definition of Federation in glossary

Owner: Prateek Mishra

Status: Open

Assigned: 30 Apr 2004

Due: ---

Comments:


#0165: Propose errata process for 2.0 specs

Owner: Prateek Mishra

Status: Open

Assigned: 22 Jun 2004

Due: ---

Comments:
Rob Philpott 2004-06-22 16:38 GMT
By the time we complete the 2.0 specs, we need an approved process for collecting and dealing with errata for the specs. Hal recommended looking at the XACML process.


#0114: Propose language to address attribute-based federation

Owner: Prateek Mishra

Status: Open

Assigned: 19 Jan 2004

Due: ---

Comments:
Prateek Mishra 2004-01-20 03:22 GMT
We could break the bilateral assumption that account linkage and
identity federation are equivalent. We could provide a unique
definition for account linkage that includes but doesn't depend
on identity federation ("one can accomplish AL through IF or
through other means, such as exchange of attributes" or similar).

Maryann:
Agrees with this idea.

Prateek:
So account linkage becomes the umbrella term. But can both IF be
accomplished without AL?

Scott:
As an example, his university has contracts with various SPs, but
Scott personally doesn't. There's an agreement to provide
service based on attributes.

A lot of people have been using account linking instead of
identity federation, because the latter has become so overloaded.

Prateek:
The notion of identity federation could be particularized as
attribute-based SSO in one case.

Scott:
We need to stress the "identity" part rather than the
"federation" part in that circumstance, but he agrees.

Eve:
Though this proposal doesn't need to address attribute-based
account linking/identity federation, we may want to add glossary
terms for that.


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


#0125: Propose language to explain that AuthNResponse may contain attribute statements

Owner: Prateek Mishra

Status: Open

Assigned: 16 Feb 2004

Due: ---

Comments:
Prateek Mishra 2004-02-16 14:46 GMT
Easy to do but needs proposal on validity of assertion life-times as well.


#0168: Provide advice on preventing caching in proxies/agents

Owner: Hal Lockhart

Status: Open

Assigned: 22 Jun 2004

Due: ---

Comments:
Rob Philpott 2004-06-22 16:47 GMT
Hal agreed to solicit expert advice on the mechanisms used to prevent caching by proxies and user agents.


#0176: Provide sequence diagrams for profiles

Owner: Jeff Hodges

Status: Open

Assigned: 23 Jun 2004

Due: ---

Comments:
Rob Philpott 2004-06-23 20:14 GMT
as discussed at F2F #5.

Diagram for BAP sent to list.


#0150: Relax Single AuthNStatement Constraint

Owner: Scott Cantor

Status: Open

Assigned: 29 Apr 2004

Due: ---

Comments:
Prateek Mishra 2004-04-29 22:02 GMT
o SC- Response Profile more extensive than that for AuthnRequest

o IR - the restriction that there be only a single AuthenticationStatement is too strict, SC- OK (will change)

*** AI: Scott: Relax AuthenticationStatement Occurrence


#0141: Review/fix boilerplace text for Artifact Protocol

Owner: Eve Maler

Status: Open

Assigned: 27 Apr 2004

Due: ---

Comments:
Prateek Mishra 2004-04-27 15:24 GMT
o Prateek: Should we sign or authenticate?

o Scott: Common language on all protocol messages.

o Prateek: Concerned about text on line 2118 "...SHOULD be signed or otherwise authenticated...."

o Scott: Not a MUST, need to provide some recommendation to protect message.

o Eve: this is boiler plate text for all messages. Need to agree on the correct text for this.

***Follow-up: Review/fix boilerplate text re: recommendation for protecting messages


#0138: Schema snippet for UID Attribute Profile

Owner: Scott Cantor

Status: Open

Assigned: 27 Apr 2004

Due: ---

Comments:
Prateek Mishra 2004-04-27 15:10 GMT
XML schema for UID/OID plus friendly name


#0160: Separate Privacy concerns language from Element/Attribute descriptions

Owner: Prateek Mishra

Status: Open

Assigned: 30 Apr 2004

Due: ---

Comments:
Prateek Mishra 2004-04-30 18:14 GMT
Jeff H - We need to highlight privacy considerations related to core, could be notes in core, could be section.
*** AI: Prateek - will generate list potential changes from core


#0178: SessionIndex clarifications

Owner: John Kemp

Status: Open

Assigned: 23 Jun 2004

Due: ---

Comments:
Rob Philpott 2004-06-23 20:16 GMT
As discussed at F2F #5:
John K. to clarity text on 909-911 on SessionIndex
and
John K. to look up why SessionIndex is required


#0132: Text to explain privacy reqts when using certain NameFormat values

Owner: John Kemp

Status: Open

Assigned: 13 Apr 2004

Due: ---

Comments:


 

 

Rob Philpott
Senior Consulting Engineer 
RSA Security Inc.
Tel: 781-515-7115
Mobile: 617-510-0893
Fax: 781-515-7020
mailto:rphilpott@rsasecurity.com

 



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