[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes for SSTC Conference Call, May 11
Attendance of Voting Members
Hal Lockhart BEA
Tim Alsop CyberSafe
John Hughes Entegrity Solutions
Paul Madsen Entrust
Miguel Pallares Ericsson
Irving Reid HP
Paula Austel IBM
Maryann Hondo IBM
Michael McIntosh IBM
Anthony Nadalin IBM
Scott Cantor Individual
Bob Morgan Individual
Prateek Mishra Netegrity
Conor Cahill Netscape/AOL
Peter Davis Neustar
Frederick Hirsch Nokia
Charles Knouse Oblix
Steve Anderson OpenNetwork
John Linn RSA Security
Rob Philpott RSA Security
Dipak Chopra SAP
Bhavna Bhatnagar Sun
Jeff Hodges Sun
Eve Maler Sun
Ron Monzillo Sun
Mike Beach The Boeing Company
Greg Whitehead Trustgenix
Attendance of Prospective Members or Observers
Dana Kaufman Forum Systems
Jason Rouault HP
Rick Randal Booz Allen Hamilton
Ronald Jacobson Computer Associates
Senthil Sengodan Nokia
Tim Moses Entrust
Membership Status Changes
Frank Siebenlist Argonne Natl Lab - Withdrew 4/27/2004
Ronald Jacobson Computer Associates - Requested membership 5/11/2004
Senthil Sengodan Nokia - Requested membership 5/11/2004
Dana Kaufman Forum Systems - Granted voting status after 5/11/2004 call
Jason Rouault HP - Granted voting status after 5/11/2004 call
James Vanderbeek Vodafone - Lost prospective status after 5/11/2004 call
AI: Blanket instruction to editors to implement the decisions made in
today's call.
Mishra, Prateek wrote:
> 1. Accept minutes from April 27 conference call
>
> http://lists.oasis-open.org/archives/security-services/200404/msg00110.html
Accepted with unanimous consent.
Addition agenda items: Should we discuss the artifact format? It will
come up as part of the review of documents.
> 2. Final dates and times for Toronto F2F
>
> Tuesday, June 15, 10:00-5:00
> Wednesday, June 16, 9:00-5:00
> Thursday, June 17, 9:00-2:00
>
> Toronto, Ontario, Canada hosted by Irving Reid, HP.
>
> http://lists.oasis-open.org/archives/security-services/200404/msg00108.html
Irving will get an email out describing the right airports. Toronto
Int'l is the usual one; the downtown airport is also really close to the
office where the meeting is being held. The address is 901 King St. W.
> 3. Vote on SAML 1.1 Overview Document (sstc-saml-tech-overview-1.1-draft-05.pdf) as Committee Draft
>
> Draft is available from
>
> http://www.oasis-open.org/apps/org/workgroup/security/download.php/6628/sstc-saml-tech-overview-1.1-draft-05.pdf
[We have more than the 2/3 of voting members necessary present, so we
can hold the vote.]
Mike McI: Question about whether this document is on a standards track?
Rob: We're just moving this to Committee Draft status, but not going
for OASIS Standard. Hal: The committee can approve something without
progressing it to a whole OASIS membership vote. Hal: OASIS generally
doesn't want all specs to remain at Committe Draft stage, but some docs
is okay. Jeff: OASIS doesn't formally have an "informational" track
like IETF; stopping at Committee Draft is roughly equivalent. Eve:
Doesn't make sense to go through the overhead of an OASIS Standard vote
for a non-normative document.
Motion to accept the V1.1 Tech Overview as a Committee Draft (Eve moves,
Jeff seconds).
Discussion on the motion: Mike/Tony: Should we do a roll call? And why
wasn't this done when V1.1 was originally approved? Eve: It was written
only during the RSA 2004 conference timeframe. Mike: Note that he's not
objecting to unanimous consent, nor asking for a roll call.
Approved with unanimous consent.
> Previously announced in message
>
> http://lists.oasis-open.org/archives/security-services/200404/msg00116.html
>
>
>
> 4. Recent document updates
>
>
>
> *sstc-saml-profiles-2.0-draft-07.pdf***
>
> http://www.oasis-open.org/apps/org/workgroup/security/download.php/6682/sstc-saml-profiles-2.0-draft-07.pdf
Scott: Section 6: Added text. Incorporated usage of statementless
assertions. Mostly the processing rules are in the other documents now.
Rob: Doesn't seem to be much controversial here.
Rob: We talked about having "attribute profiles" too. Do we need a
separate document for that? Scott: Would want to put them in the
profiles document. Eve: Does this mean that the Baseline Attributes
document (now called Attribute Profiles) should be incorporated here?
Scott: Maybe.
Prateek: May make sense for the attribute stuff to be its own chapter.
Rob: Maybe the whole profiles document needs to be renamed. Eve: What
do we mean by this whole concept?
Rick: Would this document be voted on separately, or as part of the
standards bundle? Rob: As part of the standards bundle. We have, in
the past, talked about having separate profiles written and progressed
by the TC, but this is just part of the main package for now.
Prateek/Scott: We could have orthogonal profiles, e.g. an attribute
profile and an SSO profile, that an implementation might be using
simultaneously. Eve: This is where our conformance document comes in,
and our understanding of conformance.
Scott: Section 1.1 in profiles doc has a couple of paras articulating
what a profile is. Some of the text is old, but a bit is new. Eve:
Okay if the "profile" concept is squishy and remains something like "an
atomic level that feeds into conformance".
Prateek: Reminds self to update the current Attributes document and
agrees to incorporate it into the Profiles document for
Scott/Frederick's perusal. Eve: Offers to copyedit.
Scott: He can define profiles (esp. name identifier mapping)
specifically on top of particular bindings and protocols, but would
rather leave it up to a conformance selection process to choose the
desired binding etc. Eve: Is okay with the latter; would still like
individual profiles covering all the protocols, even if they're thin.
AI: Scott to update name identifier mapping profile and add new profiles
that are somewhat binding-independent, to cover (e.g.) the query protocols.
> sstc-saml-bindings-2.0-draft-10.pdf
>
> http://www.oasis-open.org/apps/org/workgroup/security/download.php/6679/sstc-saml-bindings-2.0-draft-10.pdf
Scott: In last week's focus call, we went through the three different
artifact formats. The consensus was that, given the metadata-related
changes regarding provisioning implementations, having a single artifact
type is probably better, and that a fixed-length artifact is better. He
proposes that we use a new fourth artifact type (since its nature is
fundamentally changing) that would have the processing semantics of the
ID-FF artifact, which is the same as original SAML but constructs the
source ID by taking a hash over the provider ID.
(See message on the list about the outcome of this discussion:
http://lists.oasis-open.org/archives/security-services/200405/msg00013.html)
Something would be needed in core, up near identifiers, as well as in
the metadata spec, to reflect this. The main change is to reference
metadata explicitly to resolve the artifact, though it's not a MUST.
This obviates the need for the URL-based one. Agreed with the previous
comment on the list that 8 bytes of randomness doesn't seem enough.
Guesses that the 20-byte length was to be convenient for a SHA-1 hash.
Irving: Agrees.
Scott: The proposal is to raise the limit and say you need more than 8
bytes of randomness (probability of collision). Elsewhere we say MUST
be <= 2**-128 and SHOULD be <= 2**-160 in avoiding collisions. Rob:
Suggests that 128 is fine (at least 16 bytes in size, padded to a total
length of 20). Jeff: We allocate 2 bytes for the type field...? Rob:
That's separate.
No objections to going ahead with this proposal.
AI: Scott to incorporate the artifact proposal to go up to 16 bytes and
add the extra semantics discussed in the focus group call.
Scoitt: Will also look at adding a location hint, which wasn't discussed
in the focus call. This would add an additional byte or two, but would
be part of the same artifact format; it would be a shorthand way of
passing the URL. Metadata already does this by extending the endpoint
type with a couple of attributes (an ID and a default flag).
Greg: This would allow the system entity to have multiple endpoints that
could be contacted. Scott: Useful for load balancing. Prateek: Why
can't people just have a web farm? Scott: There are two different
systems making calls to the web farm, and they may not share the same
incidental route. Greg: You have to be prepared when receiving a
request to make a back-end call to the right location, as opposed to
directing the person retrieving the artifact to the correct system.
Prateek: Is this a peculiarity to an implementation? Hal: You need a
high-speed back channel. You can only use the artifact once, so you
need to propagate all the necessary information to the system that needs
it. Scott: This would allow for much greater flexibility in
implementing the protocol. Prateek: Wants more discussion on this point.
Greg: We have this mechanism in the assertion consumer service, so it's
already in one direction, but not in the other yet. Scott: Wants to
argue vehemently for adding this; it's why they hadn't implemented the
artifact profile before. This would allow for stateless implementation
and avoids requiring a database store.
Rob: Let's take this to the list.
Greg: Had an action item (#147) on the GZP encoding. Here's an update:
Where we were referencing the GZIP spec, it might make more sense to
reference the underlying spec for the unencumbered "deflate" compression
algorithm. Suggests this because what GZIP adds is the ability to add
metadata about files, like modification time. Still working on this
action item.
New draft core-11:
http://www.oasis-open.org/committees/download.php/6709/sstc-saml-core-2.0-draft-11-diff.pdf
Eve: Two changes here: Versioning wording to match TECH-2, and also
yanked ValueType. Has heard that the XACML folks aren't planning to use
any attribute profile(s) we come up with; it would be good for us to
work with that community to try and ensure that our profile gets them at
least part of the way towards their goal, so they can build on it.
Hal: Agrees with the goal of creating something useful. Tim: The XACML
comunity will want to add a way to supply URI-based type information.
Anne has offered to submit another SAML profile document along these
lines to the SSTC. Eve: The SAML V2.0 timeframe is pretty short! Hal:
This would be a SAML profile for XACML.
AI: Eve to contact Anne Anderson to see if the "SAML profile of XACML"
timeframe and the SAML V2.0 timeframe line up.
> *sstc-saml-2.0-issues-draft-09-diff.pdf*
>
> http://www.oasis-open.org/apps/org/workgroup/security/download.php/6546/sstc-saml-2.0-issues-draft-09-diff.pdf
The current priority-B items are:
CORE-14, 16, 17, 24, 25
TECH-1, 4
AI: Eve to update the issues list to accord with decisions made on this
call.
CORE-14:
Ron: Understand was that in SAML V2.0, there would be a URI that
resolves to all the necessary information. He hopes that there's a
simple URI, even though everyone always says "metadata". Scott: Right;
you either have a URI mechanism, or an assertion ID that's a key into
metadata. The URI binding is still in the bindings document.
Ron: All we need is a URI that identifies where to go and what assertion
to get. The SAML token profile uses the notion of an authority binding;
it will switch to URIs as soon as it gets revved to a SAML V2.0 basis.
Can close this issue with no action.
CORE-16:
Eve: There are two issues here: naming of "identifiers" and truncating
other names for brevity and consistency. XML has a magic type of "ID",
which a lot of software and people assume is the type of any attribute
with the *name* "ID". Scott: But note that this assumption is
inconsistently implemented, and constitutes a security risk!
Eve/Irving: There are also some organizations that have defined global
attributes of type ID, e.g. xml:id from W3C and wsu:Id. Scott: But this
isn't as useful as it seems, since our historical path was to give
different names already.
Scott: Some of the security risks are more theoretical than real, but
they make people uncomfortable.
Scott/Jeff: The main reason to do name changes is for brevity and
consistency. Jeff: As long as the patient is on the table and he's
opened up, I would change all these. :-)
All: Decided to go through the list of five categories one by one and
assess them individually. Eve: Reminds us that we agreed, as a V2.0
design principle, not to create gratuitous backwards incompatibilities
in service of elegance. Others: But a lot of these inconsistencies came
from the introduction of Liberty stuff, and are therefore new.
1. In elements, s/Identifier/ID/
Eve moves, Hal seconds.
Motion passes with unanimous consent.
2. Attributes of type ID should be called simply "ID"
(that is, remove any prefix that is currently present)
Eve moves, Irving seconds.
Motion passes with unanimous consent.
AI: Eve to add an issue to look into why the IDPEntry element has an ID
attribute of type anyURI.
[Prateek drops off]
3. In elements and attributes, s/Authentication/Authn/
(and doublecheck and fix any cases of "Auth" alone)
Eve moves, Jeff seconds.
Motion passes with unanimous consent.
(Note that this applies to types too.)
4. In elements, attributes, and types, s/Authorization/Authz/
Eve moves, Scott seconds.
Scott: One argument against is that we've "frozen" authz
functionality.
Greg: The namespace is new, so it's fair to rename it.
Motion passes with unanimous consent.
5. Remove duplicated prefixes on subelements and attributes of elements
Scott/others: Since we use global elements, maybe for those we should
keep the names spelled out.
Scott: To still get some brevity, we could s/Confirmation/Conf/.
AI: Eve to come back to the group with a new round of suggestions based
on the discussion of point #5 above.
CORE-17:
Eve: Own engineers didn't agree with her suggestion on this! They
prefer an unordered bag. Scott: Agrees with them! And likes the idea
of saying, on individual conditions, what the processing rules are
regarding multiple occurrences. Eve: Wants to withdraw the suggestion.
AI: Scott to revise the wording for all condition elements, where
appropriate, to say that only one occurrence is allowed.
This item can be closed.
CORE-19:
Scott: This issue is the motivator for putting something about
"identifying system entities" in the core spec.
CORE-24:
Eve: Moves to s/DoNotCacheCondition/OneTimeUseCondition/
Hal: Seconds.
Motion passes with unanimous consent.
CORE-25:
We need John Kemp for this discussion.
TECH-1:
Deferred.
TECH-3:
Scott: Ron is on the call; let's talk about this one. Slightly modified
wording around "holder of key" is in profiles-07, lines 193-196.
Eve: Has sent mail to Ron with the wording in profiles-07 that needs to
be reviewed.
TECH-4:
Deferred.
Eve: We're in good shape on the issues list.
> 5. Open Action Items
Recent messages have responded with status on many of these items:
Scott's status:
http://lists.oasis-open.org/archives/security-services/200405/msg00024.html
Eve's status:
http://lists.oasis-open.org/archives/security-services/200405/msg00023.html
Hal's status:
http://lists.oasis-open.org/archives/security-services/200405/msg00021.html
Specific status discussed in this call is below.
> *#0162*: Proposal to replace SAML AuthenticationMethod Ids
>
> *Owner*: John Kemp
>
> *Status*: Open
>
> *Assigned*: 11 May 2004
>
> *Due*: ---
>
> *Comments*:
> Prateek Mishra 2004-05-11 05:37 GMT
> Replace AuthNMethod Ids by AuthNContext framework
>
> Scott, Bob: Maybe there is not enough context in the original definition
> anyway, not very clear what
> X.509 means, for example, could SSL-based mutual authentication fall into
> this category?
>
>
> Jahan: X.509 is not very descriptive, need more detail.
>
> Bob Morgan: suggests we proceed with a fresh approach based on our current
> understanding of these
> matters.
>
> *
> ------------------------------------------------------------------------
> *
>
> **
>
> *#0161*: Remove KeyInfo from Assertion top-level
>
> *Owner*: Eve Maler
>
> *Status*: Open
>
> *Assigned*: 30 Apr 2004
>
> *Due*: ---
>
> *Comments*:
> Prateek Mishra 2004-04-30 18:16 GMT
> o Mike - what is difference in meaning for KeyInfo at top versus KeyInfo
> inside SubjectConfirmationData
>
> o Eve - no, just a syntactic
>
> o discussion ensues, decision to remove KeyInfo
>
> o Prateek - eliminating holder of key, Ron will have comments
>
> o Decision - remove KeyInfo, allow within SubjectConfirmationData
>
> *** AI - Eve to implement decision on core 18 after checking with Ron
>
> *
> ------------------------------------------------------------------------
> *
>
> **
>
> *#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
>
> *
> ------------------------------------------------------------------------
> *
>
> **
>
> *#0158*: Propose changes to definition of Federation in glossary
>
> *Owner*: Prateek Mishra
>
> *Status*: Open
>
> *Assigned*: 30 Apr 2004
>
> *Due*: ---
>
> *Comments*:
>
> *
> ------------------------------------------------------------------------
> *
>
> **
>
> *#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
>
> *
> ------------------------------------------------------------------------
> *
>
> **
>
> *#0155*: Message asking if deprecation of AuthenticationMethod is acceptable
>
> *Owner*: Prateek Mishra
>
> *Status*: Open
>
> *Assigned*: 30 Apr 2004
>
> *Due*: ---
>
> *Comments*:
>
> *
> ------------------------------------------------------------------------
> *
>
> **
>
> *#0154*: Schema changes so that AuthenticationMethod and AuthContext are
> parallel choices
>
> *Owner*: John Kemp
>
> *Status*: Open
>
> *Assigned*: 30 Apr 2004
>
> *Due*: ---
>
> *Comments*:
> Prateek Mishra 2004-04-30 17:58 GMT
> We need to resolve if we will deprecate SAML AuthenticationMethod
>
> *** AI: On hold - make schema changes so that AM and AuthContext are
> parallel choices
>
> *
> ------------------------------------------------------------------------
> *
>
> **
>
> *#0153*: add ReauthenticateOnOrAfter
>
> *Owner*: Scott Cantor
>
> *Status*: Open
>
> *Assigned*: 29 Apr 2004
>
> *Due*: ---
>
> *Comments*:
>
> *
> ------------------------------------------------------------------------
> *
>
> **
>
> *#0151*: Limit number of supported combinations
>
> *Owner*: Prateek Mishra
>
> *Status*: Open
>
> *Assigned*: 29 Apr 2004
>
> *Due*: ---
>
> *Comments*:
> Prateek Mishra 2004-04-29 22:04 GMT
> o PM- just because we can do it 3 ways doesn't mean we have to define
> them as SAML approved. Need to pull their weight. Somebody needs to
> drive this discussion. So who is going to this?
>
> *** AI: Prateek takes ownership of driving a discussion on limiting
> combinations.
>
> *
> ------------------------------------------------------------------------
> *
>
> **
>
> *#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
>
> *
> ------------------------------------------------------------------------
> *
>
> **
>
> *#0148*: Artifact format proposal for SAML 2.0
>
> *Owner*: Jeff Hodges
>
> *Status*: Open
>
> *Assigned*: 29 Apr 2004
>
> *Due*: ---
>
> *Comments*:
> Prateek Mishra 2004-04-29 21:58 GMT
> o An action is needed to propose artifact types; SAML and Liberty have
> different types, and Liberty's includes metadata.
>
> o Prateek believes that convergence on a single type is desirable, and
> that this should have been done in SAML 1.1;
>
> o Jeff Hodges agrees with this goal, but Rob sees this as less important.
>
> o Liberty's artifact format contains a hash of a provider's identity,
> which doesn't permit metadata lookup. Backward compatibility will need
> to be considered if and as new types are specified.
>
> *** AI: Jeff Hodges will make a concrete proposal for a common artifact
> format.
>
> *
> ------------------------------------------------------------------------
> *
>
> **
>
> *#0147*: Chairs to solicit comment from saml-dev on gzip encoding
>
> *Owner*: Prateek Mishra
>
> *Status*: Open
>
> *Assigned*: 29 Apr 2004
>
> *Due*: ---
>
> *Comments*:
> Prateek Mishra 2004-04-29 21:57 GMT
> Prateek wants to avoid having multiple encoding methods, and a working
> consensus in favor of the gzip approach appears to be developing.
>
> o Jeff Hodges suggests that implementers' comments be solicited, and
> Prateek recommends that the chairs send a message to the saml-dev list.
>
> *** AI: Chairs to solicit comments.
>
> *
> ------------------------------------------------------------------------
> *
>
> **
>
> *#0146*: SOAP Binding works with WSS Model
>
> *Owner*: Hal Lockhart
>
> *Status*: Open
>
> *Assigned*: 29 Apr 2004
>
> *Due*: ---
>
> *Comments*:
> Prateek Mishra 2004-04-29 21:54 GMT
> *** AI: Hal: Look at SOAP binding and make sure hand waving on
> WS-Security works.
Hal sent messages to the list today and on April 13 about this:
http://lists.oasis-open.org/archives/security-services/200405/msg00021.html
========
The only suggestion I have is to change the last sentence of sections
3.2.2.3, 3.2.2.4 and 3.2.2.5 from:
[Authentication | Integrity | Confidentiality] mechanisms designed
specifically for SOAP message exchange MAY also be utilized.
to something like:
When [Authentication | Integrity | Confidentiality] at the SOAP messsage
exchange layer is required, the use of the mechanisms specified by
[reference to OASIS WSS Std] is RECOMMENDED.
========
Hal moves, Maryann seconds.
Motion passes with unanimous consent.
AI: Hal and Maryann to uncover existing wording for describing SOAP so
it can be put into Section 3.2 of the bindings document.
Adjourned. (No more notes appear below.)
>
> *
> ------------------------------------------------------------------------
> *
>
> **
>
> *#0145*: Encryption Schema and Examples
>
> *Owner*: Hal Lockhart
>
> *Status*: Open
>
> *Assigned*: 29 Apr 2004
>
> *Due*: ---
>
> *Comments*:
> Prateek Mishra 2004-04-29 21:53 GMT
> Hal: Summary: agreement to encrypt SAML Attribute Statement. Allow
> encryption of Assertion Statement, NameIdentifier and Attribute Statement.
>
> *** Follow-up: Need schema and some examples.
>
> *
> ------------------------------------------------------------------------
> *
>
> **
>
> *#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.
>
> *
> ------------------------------------------------------------------------
> *
>
> **
>
> *#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
>
> *
> ------------------------------------------------------------------------
> *
>
> **
>
> *#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
>
> *
> ------------------------------------------------------------------------
> *
>
> **
>
> *#0140*: Update extensions element to use ##other
>
> *Owner*: Eve Maler
>
> *Status*: Open
>
> *Assigned*: 27 Apr 2004
>
> *Due*: ---
>
> *Comments*:
> Prateek Mishra 2004-04-27 15:22 GMT
> Scott - added Extensions element - modeled to be consistent with SOAP
> header element - i.e. multiple extensions within one Extensions (header)
> element.
> o Discussion of ##any vs. ##other.
>
> o Should use ##other.
>
> o Scott - should we have a wrapper element for extensions?
>
> *** Follow-up: Resolution: change Extension to use ##other
>
> *
> ------------------------------------------------------------------------
> *
>
> **
>
> *#0139*: Followup on a recipient attribute for the encryption key
>
> *Owner*: Scott Cantor
>
> *Status*: Open
>
> *Assigned*: 27 Apr 2004
>
> *Due*: ---
>
> *Comments*:
> Prateek Mishra 2004-04-27 15:20 GMT
> Eve reviews EncryptedNameID
> o Scott mentions 0 or more key distribution for Enc NameIDs. Scott also
> mentions 'recipient' attribute for the key - do we want to make that a MUST?
>
> *
> ------------------------------------------------------------------------
> *
>
> **
>
> *#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
>
> *
> ------------------------------------------------------------------------
> *
>
> **
>
> *#0137*: Propose text for core on validity of assertions
>
> *Owner*: Bob Morgan
>
> *Status*: Open
>
> *Assigned*: 27 Apr 2004
>
> *Due*: ---
>
> *Comments*:
> Prateek Mishra 2004-04-27 15:07 GMT
> http://lists.oasis-open.org/archives/security-services/200404/msg00048.html
>
> *
> ------------------------------------------------------------------------
> *
>
> **
>
> *#0136*: SSO Validity Proposal to be moved into bindings draft
>
> *Owner*: Scott Cantor
>
> *Status*: Open
>
> *Assigned*: 27 Apr 2004
>
> *Due*: ---
>
> *Comments*:
> Prateek Mishra 2004-04-27 15:02 GMT
> - Scott to implement SSO validity from proposal into
> next draft
>
> *
> ------------------------------------------------------------------------
> *
>
> **
>
> *#0135*: Why does signature need to be the first element?
>
> *Owner*: Eve Maler
>
> *Status*: Open
>
> *Assigned*: 27 Apr 2004
>
> *Due*: ---
>
> *Comments*:
> Prateek Mishra 2004-04-27 15:00 GMT
> - Eve to ask Bhavna to post motivation for moving Signature to
> front
>
> *
> ------------------------------------------------------------------------
> *
>
> **
>
> *#0134*: Availability of GZIP Implementations
>
> *Owner*: Greg Whitehead
>
> *Status*: Open
>
> *Assigned*: 27 Apr 2004
>
> *Due*: ---
>
> *Comments*:
> Prateek Mishra 2004-04-27 14:58 GMT
> - Greg to ensure that readily available GZIP implementations
> can conform to our description in bindings
>
> *
> ------------------------------------------------------------------------
> *
>
> **
>
> *#0133*: Review role of EncryptedNameID recipient attribute
>
> *Owner*: Scott Cantor
>
> *Status*: Open
>
> *Assigned*: 13 Apr 2004
>
> *Due*: ---
>
> *Comments*:
>
> *
> ------------------------------------------------------------------------
> *
>
> **
>
> *#0132*: Text to explain privacy reqts when using certain NameFormat values
>
> *Owner*: John Kemp
>
> *Status*: Open
>
> *Assigned*: 13 Apr 2004
>
> *Due*: ---
>
> *Comments*:
>
> *
> ------------------------------------------------------------------------
> *
>
> **
>
> *#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?
>
> *
> ------------------------------------------------------------------------
> *
>
> **
>
> *#0130*: Respond to paper on SAML 1.1 Browser Profiles
>
> *Owner*: Prateek Mishra
>
> *Status*: Open
>
> *Assigned*: 29 Mar 2004
>
> *Due*: ---
>
> *Comments*:
> Prateek Mishra 2004-03-29 17:04 GMT
> Maryann Hondo and Prateek Mishra to draft response to paper by Thomas Gross.
>
> *
> ------------------------------------------------------------------------
> *
>
> **
>
> *#0128*: Liason with XRI Data Interchange
>
> *Owner*: Hal Lockhart
>
> *Status*: Open
>
> *Assigned*: 02 Mar 2004
>
> *Due*: ---
>
> *Comments*:
> Prateek Mishra 2004-03-02 04:33 GMT
> Hal will generate a posting on possible need to liaison.
>
> *
> ------------------------------------------------------------------------
> *
>
> **
>
> *#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.
>
> *
> ------------------------------------------------------------------------
> *
>
> **
>
> *#0123*: Obtain MIME type registration for HTTP lookup of SAML
>
> *Owner*: Jeff Hodges
>
> *Status*: Open
>
> *Assigned*: 13 Feb 2004
>
> *Due*: ---
>
> *Comments*:
>
> *
> ------------------------------------------------------------------------
> *
>
> **
>
> *#0117*: Describe use-cases for attribute-based SSO in relationship to
> ID-FF 1.2 NameIdPolicy
>
> *Owner*: Prateek Mishra
>
> *Status*: Open
>
> *Assigned*: 11 Feb 2004
>
> *Due*: ---
>
> *Comments*:
>
> *
> ------------------------------------------------------------------------
> *
>
> **
>
> *#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
>
> http://lists.oasis-open.org/archives/security-services/200312/msg00064.html
>
> *
> ------------------------------------------------------------------------
> *
>
> **
>
> *#0105*: Respond to IBM Analysis Paper
>
> *Owner*:
>
> *Status*: Open
>
> *Assigned*: 19 Jan 2004
>
> *Due*: ---
>
> *Comments*:
> Prateek Mishra 2004-01-19 23:09 GMT
> - [ACTION] Scott & Tony to make recommendations based on IBM security
> analysis paper
--
Eve Maler +1 781 442 3190
Sun Microsystems cell +1 781 354 9441
Web Products, Technologies, and Standards eve.maler @ sun.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]