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: [security-services] agenda: SSTC telecon meeting tuesday 12-Nov-2002

Minutes from prior meeting...





Agenda Items for 12-Nov-2002...

1. Roll Call

2. Approval of prior meeting's minutes (see ref above)

3. Agenda bashing

4. Review of open Action Items (AIs)...


AI-6. Jeff to determine if conformance language around the notions of
      profiles vs. extensions is really an issue

[still in progress (will try to before next meeting)]

AI-7. Prateek & Jeff to look at Liberty provider metadata's applicability 
      for SAML specs

[in progress & forthcoming - can discuss on the call]

AI-8. Jeff to solicit comment on draft-sstc-xmlsig-guidelines-0{2|3} from
Liberty arena.

[in progress - have commitment from Jonathan Sergent to review the -03 rev of
the guidelines. Good news is that Liberty folk and SAML folk are on same
wavelength wrt to xmldsig. ]

AI-10. Eve, Rob and Jeff to draft amended SSTC charter

[in progress, will do this week]

AI-12. Prateek to draft analysis of use of XML Encryption in SAML.

AI-14. Hal to get a proposal crafted to make this schema change for
"Standardize Issuer Name Format" needed by XACML.


AI-15. Editors to update documents with Eve's fragment ID recommendations.

AI-16. Jeff & Eve to add parts of Eve's fragment ID recommendation to 2.0 item

[will do this week]

AI-17. Hal to propose specific schema changes for proposed DoNotCache


AI-18. Irving to consult w/ Merlin Hughes on current XMLDSig issues. 

AI-19. RobP will go back and look in issues list and see what he can come up
with wrt item [A.3] in the SAML v1.1 to-do list. 


5. SAML v1.0 OASIS-wide vote 

SAML is now "OASIS Standard" maturity-level. We're (effectively) done.

Need to update specs with maturity-level, new dates, filenames, etc.

Raises question of canonical location of OASIS-std specs, Eve will be looking
into this.

6. Resignation of present co-chairs; nomination & election of new.

[security-services] stepping down as co-chairs

Need to vote on nomination method. "nominations can come from the floor just
like motions," which would be the simplest.

need to decide what nomination acceptance window is, and when vote will be

suggestion: nomination acceptance begins now, thru Mon 18-Nov. Have special
election concall next week (in this timeslot?), and then new co-chair(s)
preside at next regularly-scheduled SSTC concall in two weeks (on 26-Nov). 

7. where are we at with a SAML v1.1?

todo list from item [A] of..

[security-services] Proposed, categorized To-Do list for SAML 1.x and2.0

> [A] Feasible Near-term high-priority items, and bug fixes
>       - Bugs that are backwards-compatible (targeted to 1.1)
>       - Functionality that's backwards-compatible/orthogonal and
>         high-priority
>       - The list as a whole can be completed in 3-6 months
>       - Any decision that needs to be made in the short term
>       - the below items are in no particular order (ie unprioritized)

  [above is the working summary of the scope of the SAML v1.1 effort]

>          - Formalizing operational agreements between sites (see Liberty
>            provider metadata schema (section 4 of [1]) and the saml-dev 
>            work [2], for examples; this is guidance/facilitation work rather
>            than protocol work)

  - above will be initiated w/ AI-7

  - who will take those results and fold-in what was learned from the 
    SAML interop event?

>          - WS-Security profile ([3], possibly to go to WSS TC)

  - done.

>          - Figure out versioning of modularly published profile and binding
>            specs

  - TBD.

  - this one has to do with how do we define and version SAML as a whole?

  - don't need to answer the below scenarios on this call, but need
    someone to sign up to consider the question and write a proposal

    - presently we refer to the "SAML v1.0 specification set", and 
      have "version" elements in assertions, request msg, and response

      what should we do if we eg rev the bindings and profiles spec 
      in the future, w/o making changes to -core ?  

      what should we do if we write a separate b2b profile spec -- 
        what's the version of that spec once approved as a OASIS std, say?

>          - Sharpen conformance language around the notions of profiles
>            vs. extensions

  - this is AI-6, in progress

>          - Express that an assertion should not be cached

  - proposal on the table

>          - Fix fragment identifier gaffe [4]

  - approved proposal on this.
  - needs to be incorp'd in specs.

>          - Standardize issuer name formats (request came from XACML)

  - this is AI-2
  - proposal on the table.

>          - Fix xmldsig issues (might turn out to be a [B] item) [5]

  - for 1.1, Scott's dsig doc to become a non-normative component of the 
    spec set. 
  - doc needs careful review & update as nec. 

8. Discussion of xmldsig guidelines

9. Discussion of credentials collection (?)

10. any other business?

11. adjourn

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

Powered by eList eXpress LLC