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: Agenda for Focus subgroup 25-Sep-2001 concall

Meeting date: Tuesday, 25 Sep 2001
Meeting time ( see also http://www.timezoneconverter.com ):
           Europe/Dublin  5-7pm
           US/Eastern     12noon-2pm
           US/Central     11am-1pm
           US/Pacific     9am-11am

Call-in information (good through end of December):
           Call-in number: (334) 262-0740
           Participant code #856956

ACTION items

ACTION: Prateek to start traceability review before the next TC telecon using
discussion-01 docs and going back to use
cases" (previous disposition: wait state)

ACTION: Jeff to send to the list Eve's proposed bibliography section
for document guidelines with his comments. ------

ACTION: Marlena to champion DS-1-02, Anonymity Technique - status after
discussion thread of 20-aug?

ACTION: Prateek to champion DS-3-03, ValidityDependsUpon [21-Aug: Prateek will
send out message within the next week to close out issue but call out

ACTION: Jeff to champion DS-4-02, XML Terminology, aka Messages and

ACTION: Krishna to drive SAML profile of xmldsig. 
[has sent msg to the list soliciting input..

ACTION: Bob B & Marlena: <Subject> in Core doc to correspond to Artifact. 
[status msg to list slated for Mon 24-Sep]

ACTION: Bob B: Return of not current valid assertions to RP (e.g. post
[text in Bob's powerpoint, and in e-mail to the list. Done. See..

ACTION: JeffH to transfer sec consideration work to Chris [in progress].

ACTION: Don: Smart client profile - develop a proposal. [to be sent out to list
by Mon 24-Sep]

ACTION: Don: to elaborate the number of 1-1 relationships and propose how
to fix the resulting scaling issues. [to be sent out to list by Mon 24-Sep]

ACTION: Gil: [DS-6-01:Nested Attributes] Not sure how SAML could address
this [revisit at next call]

ACTION: Prateek: To make a proposal on the mandatory use of HTTPS [was Gil's;
Report back by Fri 28-Sep]

ACTION: Hal & Bob B: Artifacts are bearer instruments, Assertions are not. 
[Done/closed. See..

ACTION: Hal: to write scenarios (and / or provide definitions) for how
NameIdentifier is used (e.g., when it is in SubjectConfirmation to identify
an assertion vs. when it is used to represent the assertion referent) 
[done. See..

ACTION: Irving: Multiple NameIdentifiers are dangerous - Irving to write
up proposal.

ACTION: Irving: to investigate and write up WAP limits
[done. see..

ACTION: Jeff: threat model discussions to be removed from the bindings
doc - but rationale preserved somewhere in SAML documents. [Will handoff to
Chris as part of sec consider work; Prateek to be consulted. This item should be

ACTION: Marlena: SHIB desires 00-02 artifact type (anonymous user &
attribute assertions - non personal identifiable info) core design issue. 
[ Marlena reconsidering need for this. status?]

ACTION: Marlena: to write a proposal to create another Web Browser
profile that retrieves an Attribute Assertion rather than an Authentication
[ Marlena reconsidering need for this. status?]

ACTION: Marlena: to write up use of artifacts for queries 
[from 18-Sep call: Query handle in request for assertion - anonymous subject
discussion will resolve this. Status?]

ACTION: Phill: Will produce a core-16 that just contains the notional and
twiddles before any major changes to schema and protocols. 
[from 18-Sep call: processing comments from eve, looking at choice groups. end
of week next. 28-Sep]

ACTION: Prateek: "Security properties of Assertion Handle" (Bob Blakley
to act as reviewer). 
[from 18-Sep call: One more cycle through bindings con-call - at least through
mid next week. Bob - may linger in review process]

ACTION: Prateek: Lookup by artifact: Agreed that he should submit a
detailed proposal to the Core outlining specific changes to specific
sections. Includes new request-response protocol not currently defined in
HTTP binding.
[from 18-Sep call: In part addressed in core-16. status by 9/20?]

ACTION: Prateek: Oracle attacks WRT SOAP Profile
[from 18-Sep call: BobB to send references to the list by 21-Sep. Status?]

ACTION: Prateek: Push profile / use case to be dropped from document
(Paul Leach's claim that this would assist SAML/Kerberos integration was
never developed - Paul to present this case if he wishes to re-instate this
out for now". Drop from Actions list?]

ACTION: Prateek: Should the Bindings Group select either the HTTP or SOAP
protocol bindings for inclusion in the final spec?
[from 18-Sep call: open - reasons for inclusion of both profiles or elimination
of 1 should be sent to the list (by 9/25)]

ACTION: Prateek: Should the SOAP binding address the issue of
intermediaries - generate proposal for how
[from 18-Sep call: SOAP Bindings will include discussion of intermediary, but
need to discuss during Focus portion (wasn't discussed on 9/18)]

ACTION: Prateek]: This is an editorial issue about the names of profiles.
Prateek to revise current document. 
[from 18-Sep call: single sign on terminology to be included in next version.

ACTION: Simon: write a concrete proposal that outlines the change to the
nature of the authorization query.

ACTION: Tim: First Contact - will write up what can be done with the
current design. 
[from 18-Sep call:to be included in next rev (-06) of bindings doc]

ACTION: prateek: pseudonym or somewhat anonymous subject identifiers

Open discussion

1. Call for items to discuss during this time.

2. Suggested topics..

2.1. Is there a concise consensus decision we can articulate for the
"Substitution Groups Reconsidered" thread, and do we need such? This msg starts
off the thread..

Eve's msg here seems to conclude it..

I interpret this portion of Eve's msg..

> the TC apparently agreed that substitution 
> groups are important in extension schemas because if you're extending a 
> "null assertion statement" (the head of the chain of assertion types, which 
> has nothing particular specified in it), xsi:type gives you no more 
> information than a substituted element would.

..as effectively saying "we won't use 'block' in the SAML schema."  Is that a
correct concise summary?

2.2 Attribute scoping (Scott Cantor). see..

2.3 Relying party tailors assertion in browser artifact profile (Tim Moses).


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

Powered by eList eXpress LLC