← Prev in month
← Prev in thread
Next in thread →
Next in month →
Consolidated minutes for Austin SSTC F2F #4 from 30-Mar thru 1-Apr
Title: Attendance of Voting Members
Attendance of Voting Members
Frank Siebenlist
Argonne Natl Lab
Hal Lockhart BEA
Tim Alsop CyberSafe
John Hughes Entegrity
Solutions
Paul Madsen Entrust
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
Frederick Hirsch
Nokia
John Kemp Nokia
Charles Knouse Oblix
Steve Anderson OpenNetwork
Jim Lien RSA Security
John Linn RSA
Security
Rob Philpott RSA
Security
Jahan Moreh Sigaba
Bhavna Bhatnagar Sun
Jeff Hodges Sun
Eve Maler Sun
Mike Beach The Boeing
Company
Greg Whitehead Trustgenix
Attendance of Prospective
Members
Nicholas Sauriol
Nortel
Membership Status Changes
Nicholas Sauriol
Nortel - Granted voting status after 3/30/2004
F2F
Jason Rouault HP -
Lost voting status after 3/30/2004
F2F
-----------------
Action Item Summary and
items that need followup:
AI: Jeff H (or Scott?):
Write up info for migration document describing Subject changes
AI: JohnK to propose
text to meet the privacy needs when using specific NameID Format values.
AI: All doc editors: We
need to update the contributors vs. the editors
Review at some future
point: EncryptedNameID recipient attribute
Resolution: Extensions
element - change Extension to use ##other
AI: Artifact Protocol: Review/fix boilerplate text re: recommendation for
protecting messages
AI: RL Bob/Irving: Need to change the wording for the first
paragraph under section 3.5.3 Processing Rules.
AI: Scott: propose change to RegisterNameIdentifier to
handle unregister case and consider specifying an attribute that
identifies intent of operation.
Follow-up: Examine SAML
schema for consistent use of XML attributes vs. elements
AI: Eve: Optional subject implemented in core spec prose.
Schema shows that subject is optional.
Follow-up: Need schema and some examples for use of encryption.
AI:
Hal: revise proposal to include decisions
made re: encryption along with details on use cases.
AI: Editors: Produce spec text that adheres to encryption
proposal for group review.
AI: Hal: Look at SOAP binding and make sure hand waving on
WS-Security works.
AI: Eve will send
a follow-up message to Anne Anderson, which may be possible to discuss at
an XACML meeting tomorrow. (This AI has already been completed)
AI: Chairs to
solicit comments on use of gzip encoding for URL encoding
AI: Jeff Hodges
will make a concrete proposal for a common artifact format.
AI: Fred Hirsch
will propose text re: FIPS cipher suites.
AI: Scott:
Relax AuthenticationStatement Occurrence
AI: Prateek takes
ownership of driving a discussion on limiting combinations.
AI: (Frederick?) ECP Section 3.3.4.1
- need to add back SOAP Header to allow an ECP to get info from the SP
without having to parse AuthnRequest.
AI: (unassigned) -
re: Validity - Document the solution proposal by which issuers are not
constrained by
AI: RL 'Bob' -
need text in Core explaining notion of ValidityPeriod is tied to 1)
AI: Scott Cantor -
re: validity - add ReauthenticateOnOrAfter
AI: On hold -
make schema changes so that AM and AuthContext are parallel choices
AI: Prateek &
Rob - send out message requesting opinions on deprecation of SAML AuthenticationMethod
URIs
AI: Scott - Determine
how Kerberos principals can be represented as NameIdentifiers.
AI: Prateek -
forward Technical Overview 1.1 to external parties that had comments on draft
AI: Chairs -
publish message to list asking for review of technical overview 1.1 and
indicate that vote to bring to committee draft will be at SSTC meeting in
two weeks from this week.
AI: Jeff H - to
propose glossary definition for binding and profile, issue TECH-4
AI: Scott -
"Binding conditions" proposal
AI: Prateek - to
review core for locations where privacy considerations are implicit
AI: Eve -
implement decision on core 18 after checking with Ron
AI: Hal - to send
focus call information to XACML list regarding SSTC focus call
AI: Rob - put Kavi
polls for location and dates for next F2F
AI: Prateek - to
put out notice to saml-dev, id-ff vendors and others for saml2 related
implementation experience, now, give early notice regarding later
attestations.
AI: JeffH - send
notice to Liberty
members requesting interest in creating SSTC implementations from parties
that have met Liberty
1.1 conformance tests
AI: Eve -
publish tentative schedule on home page
AI: Eve to
publish core-09 by Tuesday
AI: Frederick to send his updates on
bindings and profile to Scott who will then incorporate additional edits.
AI: John H -
draft of technical 1 pager with final deadine end of April
Deferred item:
Discuss ITU-T status at upcoming con-call.
Deferred item: Baseline
Attribute Status and Next Steps - sstc-hughes-mishra-baseline-attributes-01
(yet to appear :-)
Deferred item: Review
AI and list and extract dates from owners/close items
Deferred item: Establish
which work items are "complete" and those that need work
Deffered item: John
Kemp - examine authentiation context method
Thurs - Frederick
----------------------------------------------------------------
Tuesday AM minutes
(compliments of John Kemp)
Accept minutes of last
meeting - no objections, so approved
Review agenda:
Hal
would like to add an item to discuss ITU-T
Frederick
- add item to discuss WS-SMS, STP
Tony - explains logistics
Eve - review scope
document + re-assess W12, W22, W23, W26
Re-assess
W12 - attrib retrieval - anyone in favour? No - change to inactive
W22
- assertion caching - anyone in favour? No.
o
Changed to inactive
W23
- security workflow - no-one knows what it is
o
Changed to inactive
W26
- dependency audit
o
Prateek cared once upon a
time, and explains
o
Hal mentions use-case of
making assertions about an issuer. Enhanced Condition definitions could support
this.
o
Changed to 'inactive'.
Review liason
activities:
W18
- SASL. Is this critical for 2.0? Kerberos profiles could use this.
Discussions ongoing, but maybe not in 2.0 timeframe.
W20
- ebMS - not for 2.0 timeframe.
Eve: Notes difference
between active and completed - completed items are basically "feature
complete".
Eve walking through
core - draft-08-diff
Ref
the XMLNS spec. - we hadn't done that before. Mostly editorial change to
introduction.
We
need to update the contributors vs. the editors. Eve explains difference
between the two lists. Add to list of 1.1 contributors. Rob mentions that
Karl has given rules on contributors.
*** Follow-up: Update
contributor/editor lists
Eve
discusses BaseNameIdentifier
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?
*** Follow-up: Review at
some future point.
AssertionURIReference
- new element - should we mention that URN would require
"special" resolution? If URL - security token reference to a SAML
assertion.
o
Scott - should probably ref SAMLBind
- this is de-referenceable using that binding.
o
Eve/Scott discuss
referencing between documents.
Eve
- re-ordered Issuer
Scott
- re-ordered the ds:Signature element on suggestion from JohnH Lighting discussions
- lighting fixed. Everything is Illuminated
Subject
discussion.
o
Irving
wonders whether we're changing too much. Eve mentions the migration document.
Scott says it's Irving's
fault. Rob + Greg says this is simpler. Conor agrees this makes processing
simpler. Eve asks for volunteer to list changes. Scott says he'll write it up.
Jeff H will do this!
*** AI: Jeff H will do this!
[Ed. I assume that Jeff has the actual AI here]
o
RLBob mentions problem
between assertions and statements. There is an implied semantic of a Subject
linked to the Assertion - just not syntactically.
DoNotCacheCondition
languuge improved by Scott.
o
Conor - does this impact
session established with SAML token?
o
FJH - this is policy
SessionIndex
- Prateek objects to MUST NOT for globally unique ID.
o
Greg thinks you need
normative langauge for this. Mentions use of the AssertionID. Scott mentions
use of AssertionID, and then asks Prateek what the use-case is. Prateek wants
to generate the same session id for each SP. Conor tries to remember what the
use-case.
o
Conclusion: Some (not
mutually exclusive) options:
1.
Use AssertionID
2.
Re-write language to be even
more specific
o
Greg presents an option to
include
*** AI: JohnK to propose
text to meet the privacy needs when using specific NameID Format values.
Eve
discusses SubjectStatement changes.
Authn
Method - TBD at this meeting
Discussion
of authentication statement vs. authentication context statement
o
Eve - better define the
terminology of AuthnContext within that element.
AttributeDesignator
- for further discussion during the meeting. Proposal added as discussed
at last F2F.
AuthZDecisionStatement
- implemented decision to freeze.
Eve
implemented changes regarding the derivation of protocols from
Request/Response
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
o
Scott: strongly suggests we
use a wrapper element for extensions, in order to better be able to better
determine the sequence of elements.
o
Eve - explains difference
between anyType, any, and anyAttribute
o
Frederick
- suggests unified model for schema extensibility (allow anyAttribute on ALL
extension elements). Maybe want to add attributes to the Assertion?
o
Scott - argue Ann's question
about anyAttribute.
o
Decision: 1) keep wrapper
element 2) use ##other for now, and maybe expand scope if we find a good
reason.
o
Discussion of extension by
extenders.
o
Tony: Provide method of
reference extensions. If I have an extension defined, and I want to reference
it, how would I do that? Add anyAttribute in useful places.
Discussion
of status codes.
o
Scott made a list in one
place.
o
Eve wanted to split them
out.
o
Rob - we need to have these
in both places - should alphabetize in the list, and then refer to them in the
protocol/profiles.
o
Rob: Do we have to expose
this much information in status responses?
o
Scott: We didn't do anything
gratuitously - tradeoff between usability and security
o
Eve mentions use of Qname in
StatusCodes for IOP causing problems.
SubjectQuery
- SessionIndex - what does it mean that Subject is now at the assertion
level? Again we need to think about Subject-less-ness.
Query
processing rules (line 1682) text revised for type hierarchy of NameIdentifiers
Scott
- revised text about what it means to match SubjectConfirmation?
Scott
explains Authentication Request protocol
o
Intent is to write a general
protocol that can be profiled for specific uses. There are many complex things
that you can do when authenticating. We took the Lib AuthnRequest, and exploded
it into fully parameterized assertion request. Profiles would then profile it
down.
o
Defined a vocab to capture
the players in several scenarios.
o
Hal: Why isn't this possible
in current SAML?
o
Scott explains use-case
o
Conor - mentions Liberty
use-case of authentication context - SP can control the strength of authentication.
Hal + Conor converse.
o
Paul: Policy advertisement
mechanism
o
Eve: Not policy.
o
Hal: Requires capabilities
not specified.
o
Scott: Authority can't
figure this out itself - request should specify input. Scott continues - is
this thing an auth authority, a credentials collector? Or what?
o
Conor: Should be a separate
discussion item on agenda
o
Eve: Have we become too
general?
o
Hal: Need a general
framework
o
JeffH: We need to review the
profiles well.
o
Eve: Can we make some slides
explaining this whole thing better?
o
Scott to try and present
this succinctly.
Tuesday PM minutes
(compliments of Paula Austel)
Discussion of Artifact
Protocol
3.5.1 ArtifactRequest
o
Scott: deliver a message by value rather than by
reference. Protocol should be done in an authenticated manner. This describes
protocol for doing dereferencing.
3.5.2 ArtifactResponse
o
Scott: Old model, sending more than one assertion,
multiple artifacts. This change lets you return one artifact tied to the
response.
o
Conor: Use case on request: HTTP redirect
o
Scott: before never had request only request/response
or response
o
Scott: If you can make an argument for needing an
artifact on one side (request or response) than you can make an argument for
the other side.
o
Conor: Can see a use case where artifact is only used
on one side
o
Scott: Trying to make a general use case and not
create special features.
o
Scott: Make passing of messages independent of
messages. Try to eliminate Post and Artifact Profiles.
o
Tim: How to handle case where response does not come
back?
o
Scott: Not specific to artifact discussion
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
o
RL Bob: Telling people who are writing bindings what
they should say
o
Scott: Also message to developers
o
Prateek: does this disallow case when you send message
over HTTP
o
Scott: It's a SHOULD (MAY would be too weak)
o
Eve: Would a reference to bindings document help?
o
Scott: In old protocol, signing was not wanted. Needed
to authenticate both parties.
o
Eve: #any should be ##any
o
John Kemp: Misleading that "any" is used
(not necessarily dangerous)
o
Eve: Need to constrain wild cards (any). Need to add
prose to define what is expected.
o
Conor: redirect is better user interface for users on
phones (need to consider this use case)
o
Eve: Need to motivate generality
o
Scott: Would need to define artifact processing for 5
profiles.
o
John Linn: First reaction, nice generalization but
it's new and scary. Seems to be a natural set of generalization.
o
Prateek: any profile that uses this would have to
verify its use.
o
Scott: choice of what to use is deployment specific
o
Prateek: Need to specify what is mandatory to
implement. Don't want customers specifying that there are 16 variations in the
spec but vendor is only implementing one.
o
Scott: Implementers prefer generality.
o
Eve: what do we say to implementers of 1.x? We have
allowed embedding protocol message in a response.
o
Eve: Can't know how we feel about this until we
discuss profiles.
o
Scott: Need to change text in bindings to match this.
o
Frederick: Need to go back and ask question about
previous section on Authn request line 1628 AssertionConsumerServiceURL
- Wording suggests it is used for only an error
(this seems too strong). ECP uses URL, not just for errors.
o
Scott: It is used only for errors.
o
Scott: What's written has to be weakened so it's not
limited just to errors (can see other uses for this).
3.5.3 Processing Rules
o
RL Bob: relationship between issuer and signer is more
restrictive here - SAML in general says nothing (they can be anything)
- For these protocols need some rationality
between the relationship of issuer and signer.
o
Irving: Could create a table that
shows relationship between issuer and signer.
o
Scott: What to do when you have metadata about signer
o
RL Bob: there will be many policies and need to
validate against policies
o
scott: id-ff - tight relationship between metadata,
signers and keys
o
Conor: somewhere in the spec there has to be rules for
signatures. We could refer that section here.
o
Irving: don't want to be specific
here about policy for validating signatures. A profile for id-ff can specify
policy for validation.
o
Rob: Can we remove the second sentence? (lines
2136-2138)
o
Scott: We should be able to remove issuer all together
o
Irving: In SAML 1.0 specifically
separated signers and issuers.
o
Tony: The first sentence (line 2136) is too strong
*** AI: RL Bob/Irving: Need
to change the wording for the first paragraph under section 3.5.3 Processing
Rules.
o
Tony: Don't want to have to validate all signatures if
more than one
o
Scott: There will only be one (multiple signatures
might be possible later)
o
Frederick: Can't you combine signature
and TLS and later decide not to validate signature because of transport over
secure channel.
o
Scott: say nothing about signatures in any of the
individual protocols. Schema permits signing of messages for protocols that do
not provide integrity protection.
3.6 Federated Name
Registration Protocol
o
Prateek: Has anyone deployed this protocol? Concerned
that this may be a niche protocol.
o
Conor: From IDP side found this useful for
consolidating accounts.
o
Scott: Get rid of restriction in red (line 2176)
"Only federated identifiers.......can be replaced and set with this
protocol...." Get rid of this text all together.
o
Eve: Have to address notion that we have multiple
protocols now.
o
Prateek: How to roll over persistent pseudonyms
o
Prateek: IDP pushes out new proposed identifier, SP
pushes proposed identifiers to IDP (more challenging)
o
Conor: Use case SP pushing ID to IDP, providers
already have a key that indexes user. Why do they have to use a different key?
Have to protect the key so that the IDP does not look at it. Can obfuscate it
in any way.
o
Prateek: Still have concerns about implementability
and deployability.
o
Eve: Need a conformance document story by next F2F
o
Conor: older systems don't cross domain boundaries but
this is changing.
o
Rob: Have to deal with attestations before we go to
standards bodies. Need implementations to justify all parts of the specs.
o
Eve: Require 3 or more attestations for use of spec.
Conformance document should reflect lines numbers targeted for attestations
(implementations).
o
Hal: Not all useful features will be implemented in
first versions of products.
o
Conor: Use case, establish initial connection with
social security number and later change the ID to something not connected to ss#
o
Eve: OASIS requires some minimal community wants this
and some companies were able to implement. SAML usually has a higher bar than
this.
3.7 Federation
Termination Protocol
o
Scott: Name is wrong. "I am no longer going to
talk about John anymore"
o
RL Bob: Unregister Name Identifier (to match Register
protocol)
o
Scott: Change RegisterNameIdentifier to deregister if
no new name identifier is specified.
o
Frederick: Is it good to overload this
function? If someone makes a programming error and forgets the name identifier
than you deregister and will not discover error until later. Can there be an
attribute to specify the intent? Better to be explicit.
*** AI: Scott: propose change to RegisterNameIdentifier
to handle unregister case and consider specifying an attribute that identifies
intent of operation.
3.8 Single Logout
Protocol
o
John Kemp: No change since last F2F. Only addition was
reason attribute. Reason for logout (previously proposed by Hal)
o
Hal: Who is doing logout and why
o
John Kemp: Still have questions on whether you want to
specify this information or not.
o
Eve: It's only a string.
o
John Kemp: Should be a URI (mistake)
o
Eve: session index changed to element (not attribute)
is this correct?
o
Conor: not attribute of Logout request (maybe this
should not be an attribute)
o
John Kemp: this should be an element in this instance
(because not an attribute of logout request)
o
Eve: throughout SAML need to examine style of
attribute versus element
*** Follow-up: Examine SAML
schema for consistent use of XML attributes vs. elements
o
Conor: If SessionIndex is required in assertion
request than it should be required here.
o
John Kemp: need to think about whether the above is
true or not.
o
Action John Kemp: Review the rational behind SessionIndex
o
Conor: Only time you wouldn't include SessionIndex is
if there is no possibility of more than one session.
o
Conor: Can you set an attribute to specify if no SessionIndex
than do a logout on all sessions.
o
John Kemp: Need to add a reason attribute on logout
request to specify if user's credentials were compromised.
3.9 Name Identifier
Mapping Protocol
o
Scott: Case where Name Identifiers are not globally
unique.
o
Conor: RSA was asking for this in Liberty.
o
Prateek: Concerned about deployment and conformance.
What is the use case for this?
o
Eve: What profiles use these new protocols?
o
Scott: Do they need to be profiled? Is there another
generality that profiling is needed.
o
Eve: Profiles are embodiment of use cases.
o
Scott: Do we need to create profiles to talk about
protocols at a conformance level?
o
John Kemp: Need to define relationships between
protocols, bindings and profiles.
o
Eve: Issue - what protocols are reflected in profiles?
o
Scott: A lot of work to create "null"
profile to hang conformance statements off.
o
Eve: Can several protocols be combined into one
profile?
Section 5
o
Needs editorial work
Document in general
o
Conor: show examples of assertions in document?
o
Eve: would also be good to show complete use cases in
implementation guide.
Proposed solution for
assertion-level subjects (includes Subject-less assertions)
o
Thread begins with
http://lists.oasis-open.org/archives/security-services/200403/msg00028.html
o
Scott: Subject may be specified in a way that is not
consistent with SAML
o
Hal: XACML policy is SAML wrapper. Policies are for
accessing resources (not defined as subjects as in SAML). In XACML refers to
system entity. No sensible use for Subject.
o
Conor: specified that subject is implied.
o
Scott: Not legal to have nothing
o
Scott: Lots of queries don't make sense without a
subject.
o
Eve: Use framework to make security assertions (with
subject-less statements). SAML changed the way subjects are handled which
creates an issue for XACML use.
o
Irving: Only profile assertions
with subject information for SAML (don't prevent some other group from using it
without subjects)
o
Conor: Can specify each statement in SAML requires a
subject.
o
Scott: Too hard to create restrictions in schema (subject
required for SAML statements). Easier to express this in prose.
o
Scott: don't want to create profiles to show
information in core (to show subjects).
o
Hal: XACML wants to do authorization decisions
correctly.
o
Rob: SAML is an assertion framework. Others might want
to use the assertion framework.
o
Conor: Summary: Ok with subject-less assertion; in
SAML we document in prose that subject is required, specified at core level and
not profile level.
*** 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.
o
Frederick: need to understand a clear
data model
Encryption
o
http://lists.oasis-open.org/archives/security-services/200403/msg00127.html
o
RL Bob: Do we need to protect a SAML message?
o
Hal: Most common cases are transport security, SOAP
security or protecting assertion (encryption)
o
Hal: Deliberately excluded all cases (encrypting any
bit). Looked for common cases.
o
Conor: Can you make a statement that if you encrypt
one attribute then you will encrypt all attributes?
o
Hal: Might not need to, an attribute might be a
password that needs confidentiality. We can add other entities to be encrypted to the list
if there are reasonable use cases.
o
Tim: Does proposal cover integrity protection?
o
Irving: Currently can sign whole
assertion; are there use cases to sign parts?
o
Scott: Encrypt content and leave element in tact or
encrypt the element and content. Scott specified encryption in a different way
than Hal did.
o
Hal: Can use the method that Scott has used.
o
Hal: proposed text assumes a new section addresses all
issues with encryption (add after section on signature). Bits of schema
explained twice. Text for each section will be different.
o
Eve: Is this really necessary to duplicate schema
snippets? In Signature there is one comprehensive example. Would prefer to see
a discussion of common aspects of encryption (and not duplicate schema).
o
Scott: Encrypt SAML attribute or SAML attribute value?
(Even though we are not encrypting a lot of that same information on the
query).
o
Hal: If query is not encrypted then you are giving
information about the response.
o
Hal: would encrypted data be stored in a database?
o
Conor: In IDFF concern about leaking information
across pseudonyms.
o
Hal: Summary: agreement to encrypt SAML Attribute
Statement. Allow
encryption of Assertion Statement, NameIdentifier and Attribute Statement.
*** Follow-up: Need schema and some examples.
o
Tony: Are you only proposing encrypting the whole
body? Does their need to be a schema change for use with WSS?
o
Greg: Section 2.1.2 of XML Encryption spec. Describes
that if you encrypt an element the attributes on that element are not
encrypted. [Small correction per Greg:
it's only when encrypting an element's 'contents' that the attributes aren't
encrypted.]
o
Irving: Need to make sure anyone
who extends statement should inherit the ability to encrypt the statement.
*** AI: Hal: revise proposal to
include decisions made here along with details on use cases.
*** AI: Editors: Produce spec text that adheres to proposal for
group review.
*** AI: Hal: Look at SOAP binding and make sure hand waving on
WS-Security works.
From Small Issues list
(see below): DoNotCache - Why?
o
Hal: Way to say validity period once.
o
Eve: could update the spec to show relationship to
validity period.
o
Conor: 3 validity times are one issue and single use
is another issue.
o
Conor: Need to say this is a one-time use token (and
time frames are still valid time frames).
o
Hal: Advisory at best. PDP could look at how it made
the decision.
o
Eve: Can we rename this to make it easier to
understand use? OneTimeUse?
Discussion on validity
period
o
Scott: Binding Condition - carry restrictions / rules
based on particular binding. Message validity not assertion validity.
o
Scott: Need 3 things:
1.
Latest time to process assertion in profile (message
expiration).
2.
Re-authenticate on or after.
3.
Assertion validity.
o
Rob: May need other conditions besides validity
period.
o
Conor: Two time periods, Consumption time period and
data content validity. Need 3 time specifications to cover these 2 periods.
o
Rob: Lifetime of use of the data in the statement has
to be tied to the statements not the assertion.
o
Conor: Need to add re-authenticate on or after.
o
Scott: Cannot make this a message transmission issue.
Need some other indicator (validity on statements), or attaching conditions to
statements. Ugliness of doing it at the statement level is overwhelming.
o
Irving: Need tight validity
interval to make sure assertion is delivered to relying party in reasonable time.
*** AI: SSTC: Scott made a concrete
proposal. Group needs to make comments on proposal.
1.
http://www.oasis-open.org/apps/org/workgroup/security/download.php/6123/sstc-cantor-profiles-draft-01.pdf
List of "small
issues" to discuss from white board (collected during the day)
o
Encryption key dist (1 or more) +
"recipient"
o
DoNotCache - Why?
o
Privacy Considerations
o
Authn Cntx (stmt, decl, claim,....}?
o
Authn Method?
o
Schema extensibility
o
any Attribute - evil?
o
"SAML Authority == IDP"?
o
Domain Model
o
Consent vs. Reason
o
Element vs. Attribute review
o
QName prefixes in status
Wednesday AM minutes
(compliments of John Linn)
Attribute changes
(topic leader: Eve Maler), based on attribute-draft-03.
Changes
have been integrated into core-08, Attribute Statements, 2.5.3.
The
current proposal has separate Name and NameFormat elements, where NameFormat
is a URI (intended to connote both the syntax and semantics of a Name); OIDs
and UUIDs, e.g., are now represented with URIs and designated NameFormat
values.
o
Scott questions value of NameFormat
in achieving uniqueness.
o
Rob observes a need for
source qualifiers to locate particular attributes as stored in different
repositories.
o
There's a sense that the
"Source" element is being used, but is currently underspecified, and
that conflicting interpretations have been taken.
o
Conor suggests that
attribute sharing should be carried out under a commonly agreed database
schema.
o
Eve observes that the
current proposal allows both unitary and qualified names.
o
Rob comments that the
"Source" element would better be placed in the designator, but Scott
responds that this would undo many of the properties desired in the
changes.
o
Prateek's needs would be
satisfied with a means to annotate attributes.
o
Following discussion, Scott
indicates that he's becoming more comfortable with NameFormat.
o
Rob would like to avoid a
requirement that Names contain URIs, which might need to be parsed (possibly by
customer code) before use.
o
Scott questions whether both
NameFormat and Source are needed if they're both likely to be used in the same
way, and/or if their usage is unclear. Among other functions, NameFormat
protects against punning in name interpretation if non-URI names may be
used.
o
Scott proposes to add
"any" attributes at two levels, and to make NameFormat optional with
default to URI; if "unspecified" is desired, that would have to be
explicitly specified.
o
Rob observes that none of
his customers are using URI or X.500 attribute names, though others believe
that URIs are or should be the common case.
o
Revisiting discussion,
"unspecified" type will become the default, and NameFormat remains as
written, but "Source" is removed.
There's
been a request from the XACML TC that ValueType for attributes become
mandatory, so as to move metadata typing "in-band", but this is
contentious in SSTC discussion and SSTC attendees have not identified a
need for this.
o
Irving
believes that XACML should apply suitable default typing behavior.
o
RL Bob echoes this
argument.
*** AI: Eve will send a
follow-up message to Anne Anderson, which may be possible to discuss at an
XACML meeting tomorrow.
Bindings/profiles
review, led by Scott.
Discussion
began with bindings-08.
o
Scott considers that one
binds a "protocol" to a "binding" to get a "protocol
binding"; in other words, "bindings" in themselves can be
protocol-independent and can be applied to arbitrary SAML protocol messages.
o
It seems confusing to use
the word "protocol" without qualification, given that it can apply
both to the upper (SAML) layer and the lower (transport) layer.
o
In the current version,
SSL/TLS text has been moved up to distribute across multiple bindings.
The
SOAP binding has been updated based on con call discussions.
Frederick
Hirsch discussed revisions regarding generation of SOAP faults, which may
not necessarily result in sending of messages; further changes will be
made to this text.
o
Scott suggests that much of
the SOAP section's conformance material be moved to other documents. The
PAOS binding refers to the Liberty PAOS specification;
o
Frederick
indicates that he's unaware of IPR related to PAOS, and Conor observes that Liberty
specifications are subject to reciprocal royalty-free licensing terms.
Scott
has added Redirect/POST and Artifact bindings to the document, where
Redirect/POST also includes access to elements via the Get method as well
as the Post method. Following discussion, he suggests that these
bindings be renamed to "by value" and "by reference";
the bindings' naming will be considered as a follow-up issue.
o
Scott proceeded to discuss
URL encoding alternatives.
o
John Kemp had provided
Liberty-based discussion of the Plain URL Encoding choice, but he and Scott
prefer use of the gzip encoding. Additional constraints (such as Liberty
applies) are required in order to maintain the Plain approach as protocols
evolve, and this has been problematic.
o
Scott notes that the gzip
approach has performed well, makes signatures easier, and can be optimized by
pre-exchange of compression dictionaries.
o
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.
o
In response to implementer
requests, Scott has recommended that form-encoded data be carried in XHTML
documents to simplify its processing.
o
Eve expresses concern about
making a normative reference to XHTML.
o
Frederick
wonders whether a simpler approach might be possible, and is concerned about
the client-side requirements that XHTML usage might imply.
Discussion
of HTTP artifact binding;
o
Scott talks through the
binding's processing steps. It is described as a composable substitute for the
Redirect/POST binding. A request can be transferred with one binding, and
its response returned with the other.
o
Scott notes that state maintenance
is necessary in order to operate in load-balancing environments.
o
Prateek observes that
deployment requirements often imply inclusion of various data in URL fields,
and that strong prohibitions are therefore inappropriate.
o
At lines 677-678, messages
intended for specific recipients must only be delivered to those authenticated
requestors.
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.
o
Scott describes the URI
binding as a specialized case, used for SAML assertion retrieval purposes but
not more generally. Unlike other bindings, it returns an assertion, not a
SAML protocol message.
o
Scott notes that entities
other than SAML authorities should be able to construct URIs that reference
SAML assertions, and the AssertionID convention with a known assertion request
endpoint supports this.
Tony
asks a question about Sec. 3.1 (SSL/TLS), noting that some customers may
require use of FIPS cipher suites, which apply only to TLS and not to
SSL. He observes that IBM has evaluated FIPS requirements, and has
concluded that non-FIPS algorithms must not be included in FIPS-compliant
deployments.
o
Hal asks what change would
satisfy this concern. This has also been discussed in WS-I.
*** AI: Fred Hirsch will
propose text.
At
line 175 of bindings, a cipher suite name is missing a WITH.
Tony
asks whether reference should be made to the WSS SAML Token profile as an
additional binding.
o
Scott believes that this
isn't a binding in the sense being discussed in the SAML binding
specification.
o
Conclusion: a reference will
be made, but in the SAML profile document rather than bindings.
Following the
morning's discussion, the agenda for the remainder of the day was
revisited, dropping the ITU-T item. Discussion of the profiles
document will move to Wednesday afternoon.
Wednesday PM minutes
(compliments of Paul Madsen)
SSO Profile Review
SC
- replaces the existing two profiles (POST & artifact).
o
Tried to define an abstract
sequence diagram modeling the abstract message exchanges
o
Six abstract steps
1.
UA access SP
2.
SP determines IDP
3.
SP issues AuthnRequest to
IDP, using UA as intermediary
4.
UA authenticates to IDP
5.
IDP issues Response message
to SP, through the UA. Message will contain at least an Assertion
6.
SP grants access or not
o
SAML 1.1 starts at Step 5
above
o
Intersite Transfer Service
exists for both ends, IDP and SP
o
Single-SignOn Service is
where the AuthnRequest (or artifact) gets sent by the UA
o
AssertionConsumer Service is
where the AuthnRespone (or artifact) gets sent by UA
o
RelayState should not
contain URL
o
PM - concern is that we end
up a combinatorial number of combinations of profiles/buildings to be
maintained at SP/IDP
o
SC-
exists in Liberty.
No value judgment, some people believe we need different mechanisms to do the
same things
o
PM- in SAML 1.1 we had very
definite mechanism
o
SC-
not a technical issue,
o
SC- 4 combinations are
from 2x2 (by value/by reference and both directions)
o
EM- what is the value of
this abstractness
o
SC-
important to define what are the requirements at each step
o
CC- this is a good
description of what's actually happening
o
EM - does this correspond to
'Destination site'
o
CC- not necessarily, this is
me browsing to the SP rather than being sent to the SP from the IDP
o
EM - destination site may be
most common but by picking it its no longer abstract
o
JH - there was a gap in SAML
1.1
o
SC - completely encompasses
what SAML 1.1 defined
o
EM- so, for conformance,
what do you have to support. Is the profile still the unit of conformance?
o
PM - we had two concrete
ways of pushing an assertion around,
o
SC - we are both combining
the two old profiles and adding new message flows
Protocol
Profile - this is where he actually profiles the protocol (the
request/response as defined in Core) - it profiles how the protocol
can be used within the SSO profile
o
EM - this can't be called a
profile
o
JL - this is the original
definition of 'profile'
SC
- Sections 3.4.1 and 3.4.2 constrain down AuthnRequest and Response
o
For AuthnRequest, the only
constraint is that there can't be a Subject. Only relevant if the SP
already knew who the User was -as might be possible for reauth
o
PM- don't want to have
to build a responder with logic for reauth
o
CC- expectation is that the
subject is the same
o
CC - probably not clearly
documented what happens if the SP sends a reauth request and the iDP creates an
assertion for a different Principal. SP has to know to look at the Subject.
SC - reasonable to allow the SP to indicate the Subject for which an Assertion
is being sought
PM - consensus is to remove the 'MUST NOT' and provide guidance prose.
o
TN - can I do these (AuthnRequest
and Response) separately?
o
SC- yes, this is conformance
question. There is 'source-site first' so you do not need to have an AuthnRquest.
o
CC- this puts a lot more
weight on the conformance doc because the conformance doc is going to define
what the required flow is.
o
FH - in the previous SAML
profiles all the details were there
o
SC- I think you are
oversimplifying some of ID-FF.
o
SC- pushing back on the
assertion that there are now all sorts of new things to be tightened up in
Conformance.
o
CC- If I read this document,
I'd assume I have to implement AuthnRequest 3 ways (re-direct, POST, and
artifact), and 3 ways for Response.
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
o
PM - I'd like to see a line
saying that the Response can carry AttributeStatements
o
TN - if there are multiple
responders, are they all constrained to meet the conditions?
o
SC- Yes, the AudienceRestrictionCondition
names the recipient, which could be a high-level entity
o
RP - it identifies the party
for which the assertion was created.
o
BN- is it a change to have a
MUST for the AudienceRestrictionCondition/
o
SC-
yes
o
BM- are there not two ways
to do the same thing now?
o
SC-
disagree
Basic
Processing Rules (wonkeeee section)
o
SC- disclaimer- you may not like
this but what I said was, to try and avoid two signature, the model is to stick
everything in the assertion and sign there.
o
PM- proposal is to remove
the signature from Response?
o
BM- we are dispensing with
the layering model to avoid multiple signatures.
o
CC- SPs have to write code
to look for signatures, much better to have one place to look
o
SC- Response serves no role
other than a Root element
o
CC- have to put things like CorrelationID
where they can be integrity protected
o
FH- so we're moving protocol
information into the assertion for performance reasons?
o
HL- so what's the
threat, if I don't have sufficient confidence...
o
HL- an assertion means what
it means independent of how I got it, worst case is I get a false reject
o
IR- if I make an Artifactrequest
and somebody can replay a different Response by playing with the InResponseTo
attribute then the Artifact could be associated with another user.
o
SA- collapsing the layers
for performance reasons seems very sad
o
CC- I'll take the hit for
the performance gain
o
HL- so what else is being
moved into the Assertion?
o
SC- .........
o
SC-
the point of the BindingCondition is a hack, its everything you would normally
put in the Response but can't because it needs to be integrity protected
by the signature over the assertion
o
JL- this is not without
precedent
o
BM- this is the other
direction though
o
BM - move that section 3.6
security Considerations be moved out of document
o
PM- consensus agreement
o
SC-
mix and matching between bindings and profiles
o
PM- need an owner to define a
limited number of ways to push an assertion from one point to another
o
SC-
not just pushing the assertion
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.
o
EM- obvious way it to make
one of each pair as mandatory to implement
o
SC-
I don't want artifact to be the mandatory one
o
PM- we need to discuss this
o
JK- also needs to
distinguish between what is mandatory to implement and what is sensible to
implement. Shouldn't give people the impression that you can take a piece
from here and there and expect things to work
o
EM- sparse matrix needs to
be determined.
Enhanced Client
Profile - Frederick Hirsch
General
discussion
o
FH- need to determine how to
reflect/incorporate Scott's proposal
o
FH- the way that ECP works
is that the SP sends an AuthnRequest to the client, and the client knows how to
get to the IDP
o
FH- went through doc
summarizing recent mods
o
JK- Device should not have
to look into the payload to see where the Response should be sent
o
CC- ran into a problem in Liberty,
the Response should only be sent to the address specified in the Response,
Shouldn't pay any attention to what might have been specified in the AuthnRequest
o
SC-
only useful for error responses
o
FH- needs to be renamed
o
JK- might be defined in
PAOS, may not have the leeway to rename, must clarify usage
o
FH- also changed messageId,
recommended that it be not used, but if used, rersponse must have correlation
*** AI: Section 3.3.4.1 -
need to add back SOAP Header to allow an ECP to get info from the SP without
having to parse AuthnRequest.
o
SC-
should our samples say SAML 2?
o
EM- just saml and samlp,
should be version agnostic
o
FH- related to that, are we
doing SOAP 1.1 or 1.2?
o
EM- assume SOAP 1.1, on the
issue list
o
CC- do we have a standard
for namespace prefacing
o
JK- may not have been
implemented
o
EM- pretty good
o
FH- changed authnResponse to
Response- consistent with everything else
Validity
FH
- what are the requirements?
SC_-
I'll try
o
seems to be consensus that NotBefore
is not particularly useful
o
3 Times (to two intervals)
o
Time during which:
- (1) assertion can be accepted/consumed by SP
- (2) assertion is considered valid
o
Time at which:
-
(3) a session initiated as a result of the profile should be killed or
refreshed
o
Scott's interpretation of
1.x is 1 and 2 are the same and extremely short and 3) was unaddressed
o
JL- in X.809 it is 2) that
is addressed
o
HL- if you look at the
revocation reasons it's clear that X.509 combines 1) and 2), the analogy
breaks down
o
CC- my interpretation is
that a SAML assertion says that a statement can't be assumed to be valid
only at the time - there is nothing in the assertion that would indicate a
longer lifetime
o
SC-
I think of 1) as having more to do with how its being passed around as opposed
to an intrinsic quality of the assertion, and therefore 1) belongs on the
Response
o
Consensus opinion was that
1) does belong on Response rather than Assertion.
o
MB-
it's the SP that really needs to specify the lifetime policy
o
CC- but the IDP's
requirements feed into this decision
o
JL - consider this example,
an attribute assertion states that an individual carries the privilege to
'carry our high value transactions'?
o
PM- how long can you depend
on the information is the key?
o
CC- validity is not just the
length of time
o
SC-
is there any sense in which the spec makes it the case that you shouldn't make
use of the attributes after a given time? When do I go back and say, 'is this
still true'?
o
BM- the mechs that X.509
provides are the CA promises that it will keep track of the information within
the cert so that an RP can ask it, and that it will respond to revocation
requests.
o
SC-
I want to push back on the statement that assertions can't be forwarded,
if not there is no point in signing
o
RP - if my assertions gets
pushed around within my infrastructure, is that forwarding/
o
ALL- no
o
PM; how do we make progress,
what is the plan?
o
RP- carefully define our use
cases
o
MB-
are we merely redefining names or are there new requirements for time
intervals.
o
JK- new requirement is ReauthenticateOnOrAfter
o
Consensus is to add ReauthenticateOnOrAfter
o
GW- there is a use case in
the Liberty Web Service world, the SP gets an assertion from the IDP and this
assertion can't be short-lived because it needs to be used in subsequent
Discovery Requests
o
PM- there is a suggestion
that the 'forwarding' use case. a solution is that the issuer of an assertion
is free to ignore the time constraints that it placed.
*** AI: (unassigned) -
Document the solution proposal by which issuers are not constrained by
*** AI: RL 'Bob' - need text
in Core explaining notion of ValidityPeriod is tied to 1)
*** AI: Scott Cantor - add ReauthenticateOnOrAfter
AuthnContext
JK-
proposal is to define a mechanism by which 3rd parties can submit
proposed Authentication Context classes
JK-
outstanding issue is that we have SAML AuthenticationMethod and we also
have Liberty
classes that subsume the SAML AuthenticationMethod, desirable to harmonize
them
JK
- initially thought that SAML AuthenticationMethods were simple and we
could do a simple 1-to-1 mapping, not that easy.
JK-
asking the group whether or not he should do the mapping?
EM-
would changing the AM URIs to classes change the semantic?
JK-
probably not
JK-
proposal is to stick with existing mechanism and defer the real work to
another time
PM-
why are we committed to keeping SAML 1.1 AM?
SA-
so why not make it a choice?
SC-
what worries me are the facilities within AuthnRequest by which an SP can
indicate its requirements
SC-
parallel issue is should we not be cleaning up the existing SAML 1.1 AMs
SC-
asking John Kemp 'do you want to make the schema changes?'
*** AI: On hold - make
schema changes so that AM and AuthContext are parallel choices
*** AI: Prateek & Rob -
send out message requesting opinions on deprecation of SAML AuthenticationMethod
URIs
EM-
confused
JK-
happy if the group decides that we should do the single mechanism
EM-
the temporary mechanism is to make changes that everywhere one occurs,
the other can occur. I'd rather not add infrastructure that it both
invasive and temporary.
SC-
it will create more work in the next transition
Consensus
- John will evaluate work scope and come back with a recommendation
Metadata (Jahan Moreh)
JM-
proposal is that we use the Entity terminology rather than iDP/SP
JM-
EntityDescriptor is core element
PM-
need to clarify relationship between ProviderId and Issuer
JM-
entity can act in one of roles, an abstract RoledescriptorType. One
concrete type is SSODescriptorType to distinguish between IKDP and SP.
PM-
do we still need PDPDescriptor? Given that we are distancing ourselvees
from this
SC-
not a large amount to worry about
PM-
what are the conformance implications?
SC-
defines additional roles that are specific to SAML (beyond those defined
by Liberty)
SC-
completely changed how endpoints are described
JM-
Prateek, you had also asked about AttributeConsumerURL to allow a
consumer to indicate what attributes a consumer might want
SC-
I defined how this would work on the consumer side, not the provider
JM-
put together text around Digital signatures; a bunch of different
elements can be individually signed. Need guidance on what should be
done. Jahan has recommended that all elements be signed individually
GW-
desirable to be able to validate one signature over the complete document
rather than multiple.
SC-
not sure what the use case would be
JM-
softter recommendation is that at least one of RoleDescriptor, or EntityDescriptor
or EntitiesDescriptor be signed
GW-
inclination would be to have a single signature at the top level.
PM-
signing model should support the distribution model.
JM-
metadata exchange will be accomplished through well know URLs exchanged
out of band
SC-
subsequent to previous F2F, Neustar has indicated that they would like to
see the DNS mechanism (as defined by Liberty)
supported.
PM-
conformance won't make these required.
Thursday AM minutes
(compliments of Frederick Hirsch)
Kerberos Proposal
Resolution
draft-sstc-solution-profile-kerberos-04
Tim
Alsop presented a whiteboard overview.
o
picture: [Active
Directory] [workstation with credential store]--[web server with
credential store]
o
Two primary use cases discussed,
(1) browser and web server with web server determinining identity of user using
kerberos (2) work station creating SAML assertion using kerberos on work
station. Not necessarily specifically a browser environment.
o
Note that "Windows integrated
authentication", or SP-Nego (SP Negotiate) is not a standard, but a
specification that was submitted as an IETF draft since expired, but
implemented. Mozilla and Apache web server plugins exist.
o
impersonation - authenticate
user at work station using Kerberos, cache credentials at web server, then web
server can authenticate elsewhere on network using those credentials. This
allows end-end authentication in a network.
Greg
W - authentication step discussed yesterday, step 4,doesn't require a
detailed SSTC specification, since many authentication methods are
possible
John
H - this could go into the technical overview document to explain how kerberos
may be used for authentication
John
Hughes presented more detailed scenario.
o
Requirement - pull or push saml
assertion to service outside the kerberos domain that produces the original saml
assertion.
1.
Authenticate to KDC at
active directory
2.
generate assertion using
authenticated principal, proprietary implementation, within kerberos domain want
to go to remote domain,
3.
AuthnRequest to SAML
component within source kerberos domain with secure connection
4.
Get samlp:Response with
Artifact or Assertion
Scott
- How to use Kerberos with SOAP is undefined, not standard
Frederick
- WSS Kerberos Token Profile would be helpful in this area
Scott
- could define DCE RPC interface to be SAML protocol, but not done
Tim
- trying various approaches, have not worked out solution at this point
Scott
- do not use Artifact unless needed.
John
H - indicated that there may be a unique issue to this profile regarding
how to push assertions, with a potential solution of using a browser
applet to send the assertion from the browser, as opposed to using the
HTML form post technique, for example.
*** AI - Scott Determine how
Kerberos principals can be represented as NameIdentifiers. 1510 possibility.
Issue
of how to support kerberos interaction discussed, possibility of using
SAML browser methods but might require knowledge of user agent
capabilities, otherwise could use SOAP technique.
Scott
- using SOAP makes it easier to address markets.
Tim
- Could also put kerberos ticket inside assertion, possible Kerberos
confirmation method.
Tim
Kerberos ticket lifetime can be passed in AuthnRequest, to address
lifetime issues.
Scott
- Schema includes Conditions to allow this
Prateek
- Part of Kerberos work will be in SAML 2.0, part will be outside SAML
2.0 but enabled by it.
John Hughes - draft 04
of technical overview published this morning
Review/approve
SAML V1.1 technical Overview as a Committee Draft (sstc-saml-tech-overview-1[1].1-draft-03)
Changes
o
comments from Frederick
incorporated
o
corrections to one of the
diagrams
o
restructured: discussion of
source site first, destination site first moved since not necessarily part of
standard
o
Conor - prefer push, pull
o
Jeff H - SAML 2.0 should
carefully define terms so we use SP or IDP, similar source and destination
o
John H - 1.1 technical
overview used older terms
o
John H - want to bring
document to closure
o
Eve - committee draft is
appropriate
o
Prateek - will forward to
external parties that had comments on draft
o
Decision: will vote to
publish as a committee draft at SSTC meeting in two weeks.
*** AI: Chair action item to
send message to list regarding upcoming vote.
Eve leads Issues list
discussion
Review
issues list (incl prioritized small issues)
sstc-saml-2[1].0-issues-draft-07
Draft
08 has not yet been published on site, discussed draft 08.
Closed
Items:
o
Core 06 - Closed - Assertion
level subject- prose based optional subject
o
Core 15 - closed - health
warning on xsi:typeExtensions
priorize
high A to lower C, A for today
Open
o
Core-7 -Soap 1.1 vs 1.2 -
priority C
1.
Scott - use of SOAP internal
to SAML, more of an issue with WSS SAML Token Profile, not in this group
o
Core 8 - open but resolved,
so priority C.
1.
Scott has details
o
Core 9 - Eve, Scott priority
C
1.
"anyAttribute
evil" response to Ann in this category
o
Core 11 - validity period -
still open
1.
Scott has short solution
proposal, priority A
o
Core 12 - add "for
issuer" to item, C
o
Core 13 - pending - resolve
by removing restriction
o
core 14 - Ron issue - need
input from Ron - B
o
core 16 - new issue,
Authentication vs Authn, decision would be helpful for cleanness and elegance.
B
o
core 17 - bag of conditions -
B
o
core 18 - could make
decision today, A
o
Bindings 3 - discuss later -
related to conformance, e.g mandatory to implement. B
o
Tech 1 - terminology as Jeff
mentioned, would like to clean up drafts earlier B
o
Tech 2 - at last F2F there
was consensus that there are no use cases, A
o
Tech 3 - impersonation -
text changes were done for KeyInfo, changes needed for holder of key, Scott may
be out of scope.
o
Tech 4 - glossary additions
- need to define binding, profile,
*** AI: Jeff H - define
binding and profiles
o
"atomic unit of
interoperability" proposed
o
Prateek - would like to
change definition federation, email thread.
o
Federation Definition -
B
Issues added during F2F
Domain
Model, "SAML Authority" == "IDP", same as Tech 1
Consent
vs Reason - B
Element
vs Attribute Review - AuthenticationMethod, SessionIndex are examples, C
QName
prefixes in Status - interop issue, new issue to add to issues list,
"Replace QNames for Status with URIs", B
Scott's
"Binding conditions"
*** AI: Scott to draft
proposal
Encryption
key (1 or more) distribution and recipient A
Privacy
considerations?
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
Rename
Authentication context statement A
AuthnMethod?
decided, Scott and John K have action associated with that.
Schema
extensibility - already issue Core-9
anyAttribute
- evil? - already issue Core-9
Issue List Detailed
Discussion of A items
Core-11
Scott described issue.
o
Conor - encryption does not
impact validity, just used for confidentiality only while passing third party
o
Scott not with name
identifier mapping, can be passed around, if not in assertion can be used.
o
Hal - needs to be in an
assertion. Why not have assertion with just name identifier in it, make
statement optional
o
Proposal - subject-less
assertion with no statements. :)
o
Can change federation time
frame by changing name in protocol
o
Prateek - potential issue,
how to define the lifetime of a federation, possibly the federation identifier
o
Greg - two lifetimes:
1-time, only for this session, or otherwise indefinite time
o
Scott Exchanging encrypted
references to principals - could hand out permanent identifier that should not
have one.
o
Conor - NameIdentifier
response includes assertion
o
encrypt name identifier -
either name identifier or assertion containing name identifier
o
Prateek All federated
identifier establishment contain time period
o
Tony - hard to manage if
mandated
o
Conor - dont want to mandate
use of assertion, want to simplify at SPs
o
Eve suggests focus group
call on the topic.
o
Conor could change name of Reauthenticate
On or after to Renew On or After...
o
Hal - relying party
decision, offering guidance
o
New issue : lifetime for
federated identifiers
o
Eve updated issues list.
core
18 KeyInfo or SubjectConfirmationData
o
Scott - should be choice
o
Prateek -some wanted both
o
Scott could put KeyInfo
inside SubjectConfirmationData
o
Eve would require explanation
o
Prateek - biometric in SubjectConfirmationData,
key in KeyInfo
o
Eve - decision to make
choice group
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
Bind-3
o
Scott draws table see PDF
sstc-f2f-sso-table.pdf. Proposed refers to Scotts refactoring presented
yesterday.
o
Concern about number of
table entries, complexity.
o
Need for different entries
to meet different requirements discussed.
o
Conor - FORM POST needed for
SPs that do not use SOAP call.
o
Scott - feels different
about Artifact vs POST
o
Hal - proposes
implementation guidelines on when to use each cell, depending on requirements.
o
JeffH - wide range of
deployment scenarios.
o
Scott - metadata Endpoint =
binding, location, location
1.
element name corresponds to
message in table
2.
binding refers to binding
column
o
Prateek - As editor of
conformance draft will start working on draft. Would like to see
Federation identifier establishment and management factored out separately from
single sign on functionality. Will raise issue of whether both will be required
for conformance to SAML 2 - issue for later discussion.
o
Scott - really wants to see
destination site first supported
o
Hal - suggests packages
o
JeffH - what does SAML 2
mean?
Hal gives summary of
XACML meeting regarding SSTC.
Next
step: propose agenda item on next SSTC focus call on relevant topics
related to type information.
XACML
members interested in topic to attend SSTC focus call.
Plan
for next Tuesday
*** AI - Hal to notify
XACML
Prateek
requests email from XACML on mail list before meeting.
Discussion
deferred until Tuesday.
Review/establish
schedule for remaining work and next F2F
Discussed
possible additional F2F, end of May beginning of June. Rob to arrange
call.
Eve
- Plan committee draft vote by end of June to start 30 day public review.
Might get enough comments to require a second committee draft.
Eve
- should get additional review earlier, drafts are public.
Scott
- once a round of changes are in we can have drafts for early review
Candidate
committee draft for final comments within TC, last call, end April 30. - include
OASIS news notice
F2F
mid-May to mid-June
*** AI: Rob to post KAVI
polls for next f2f
CD
+ 30 day public review, end-June
Collect
attestations: now to Aug 15
*** AI Prateek to contact
ID-FF vendors
OS
Balloting request Aug 15
Conor
- suggests contacting Liberty
vendors that have certified 1.1 Liberty
conformance.
*** AI: JeffH to send query
to Liberty
members
Eve
- last call must include delta document, 1 page technical overview
Burton
Catalyst is mid-July, July 21-23, possible outreach
Eve - motion to thank
Tony and IBM for hosting, much appreciated hospitality.
Motion
passed without objection.
Meeting Adjorned.
Rob Philpott
Senior Consulting Engineer
RSA Security Inc.
Tel: 781-515-7115
Mobile: 617-510-0893
Fax: 781-515-7020
mailto:
← Prev in month
← Prev in thread
Next in thread →
Next in month →