← Prev in month
← Prev in thread
Next in thread →
Next in month →
UPDATED Consolidated f2f5 minutes
UPDATED: Consolidated minutes for SSTC SAML V2.0 F2F #5,
Tues-Thurs 15-17 June 2004 (Updated with Thursday morning minutes)
======================================================================
Summary
======================================================================
Votes:
·
None - quorum not achieved
New Action Items (Note that this list simply consolidates
the items in the raw minutes that were highlighted as AI’s. There are
additional items that folks said they would do that are described in the
minutes. Everyone should review the raw notes for any items they agreed to
take on):
1. Editors to
resolve submission process for additional Authn Context classes / Bindings /
Profiles
2. JohnK and
Scott to move Authn Context Declarations to XML Schema centric approach
3. Scott to
ping Peter for additional text, subsequent to that there will need to be a
review to ensure that the appropriate SHOULDs etc are there.
4. Scott to
reorganize section 4 (Metadata) to clarify
5. Scott to clean
up the text around the different types of profiles in Section 1.1
6. investigate
profile designator for statement and query - potentially allowing for endpoint
metadata
7. Scott to
talk to RL Bob (re: BER & DER issues in LDAP/X.500 profile?)
8. Prateek to
ping John H for clarification (re: UUID’s being used with attribute
values)
9. Scott to
incorporate into document. include reeference to Appendix A. (re: XACML
profile)
10. Need
clarification as to what is the target namespace for the DataType element? (re:
XACML profile)
11. Paul Madsen
to take the exec overview document
12. Scott will
investigate use of wiki on Oasis site
13. chairs to
put item regarding errata process on the concall agenda
14. (Jeffh)
Resolve status of RFC (re: syntax of UUID as URI)
15. (Scott) to
document the well-known values for the DCE attribute name
16. (Scott) Will
fix spec. to be more precise about use of encryption with name identifiers (per
discussion on PKI-based attr profile)
17. Rick R. (and
customer) should read and accept the OASIS IPR policy for document submission
18. (chairs)
discuss + resolve general approach to new profiles
19. Jeff to add
security context to Glossary
20. Jeff to help
with sequence diagrams for profiles
21. Rob to
enumerate the implementation declarations/claims of interest. Prateek and Scott
will contribute.
22. Hal will
look at OneTimeUse text again and attempt to clarify
23. John K. to
clarity text on 909-911 on SessionIndex
24. John K. to
look up why SessionIndex is required
25. Scott to
o
propose alternate text for section
3.2.3.1
o
strike 3.2.3.2-3.2.3.4.
o
rewrite 3.2.2.3-3.2.2.5
26. Hal to get
expert advice on how to prevent caching by proxies and user agents
27. JohnL and
Prateek to draft up a document commenting on, acknowledging, and clarifying
certain points in the IBM Research Report RZ 3501 (# 99427) 06/30/03
New Issues:
Deprecation/removal of XKMS
authn context class
Versioning in Profiles and
Metadata
How to represent support for
attribute profiles in metadata
Verify purpose of
EncryptionMethod in KeyDescriptor in metadata
SSO profile is different in how
role division is split across request response
SSODescriptorType shouldn't be
a base
Need new name for
AttributeRequestingService
Existing Issues:
Because of lack of quorum,
recommendations will be made for resolution at the next quorum call.
Refer to the ISSUES list recommendations at the end of the raw minutes
text.
======================================================================
Raw Notes
======================================================================
[Steve Anderson begins as minute-taker]
Roll call
Quorum NOT achieved
Attendance of Voting Members -
This includes those folks that dialed in for portions of the meeting:
·
Conor P. Cahill AOL, Inc.
·
Hal Lockhart BEA
·
Rick Randall Booz Allen Hamilton
·
John Hughes Entegrity Solutions
(dial-in)
·
Paul Madsen Entrust
·
Dana Kaufman Forum Systems
·
Irving Reid Hewlett-Packard Company
·
Michael McIntosh IBM
·
Scott Cantor Individual
·
Prateek Mishra Netegrity
·
Frederick Hirsch Nokia
·
John Kemp Nokia
·
Charles Knouse Oblix
·
Steve Anderson OpenNetwork
·
Darren Platt Ping Identity (dial-in)
·
John Linn RSA Security
·
Rob Philpott RSA Security
·
Jahan Moreh Sigaba (dial-in)
·
Jeff Hodges Sun Microsystems
Membership Status Changes
·
Gavenraj Sodhi Computer Associates -
Lost voting status after 6/15/2004 F2F
·
Emily Xu Sun - returned from LOA
6/14
Accept minutes from previous
meeting, 8 June 2004
http://lists.oasis-open.org/archives/security-services/200406/msg00050.html
http://lists.oasis-open.org/archives/security-services/200406/msg00054.html
·
Quorum not achieved
Spec Review: Authn Context,
Metadata, Profile
- John Kemp walking thru Authn Context doc (draft 5, PDF)
- discussion of need for process for registering new
context
classes
- Hal: process should just verify
that doc is in right form,
rather than verifying technical
merits
- JohnK: line 4849, copied from
other SAML docs
- Conor: do we need sanity check for
new classes?
- Paul: thinks so
- Conor: in Liberty, we needed it
- Scott: sees difference in
accepting for web site, and accepting
into core doc set
- Jeff: let's not rathole on this
now, just leave this section
(5.5) TBD
- JohnL: don't want to appear to
make commitment to post any
submission on website
- JohnK: proposed text?
- Scott: if we change this, we need
to change other docs
- Conor: OK for anyone to submit
anything, as long as we categorize
sanctioned vs. not sanctioned
- Hal: IPR issues with submissions
... but not going to rathole
on that now
- Prateek: thinks the stated
guidelines are helpful
- [ACTION] Editors to resolve
submission process for additional
Authn Context classes / Bindings /
Profiles
- Conor: care should be taken to try
to define new submissions as
member of existing class, rather
than entirely new class
- JohnK: implemented Eve's suggestion: Authn
Context Statement ->
Authn Context Declaration
- need to clean up capitalization
- JohnK: implemented former Authn Method as
Authn Context Class
- Paul: noticed reference to Authn Method
that needs to be
updated (line 121-122)
- JohnK: will fix
- JohnK: (line 2827) declarations must
conform to a class
- discussion of formal XML issues around
AuthnContextDeclaration
- taking example of Password (line 3712,
with real example starting
on 3769)
- Scott: this is not any formal use of XML
Schema that you would
ever find
- it's a documentation use
- Prateek: and the reason for not putting
this in a schema-centric
model was expedience?
- Paul: (originally did this work in Liberty) basically
- Jeff: we're talking about putting
machinery into the schema that
would enforce lines 3797-3799?
- Scott: yes
- JohnK: as well as lines 2827-...
- Scott: doesn't think this is a big effort,
and even willing to
do the work
- discussion of derivation by extension vs.
derivation by
restriction
- Conor: has received feedback, falling into
two cases
- authn context has to be explicitly
recognized
- authn context has to be "at
least" X
- [ACTION] JohnK and Scott to move Authn
Context Declarations to
XML Schema centric approach
- Rob: schedule is tight, so can this work
be done in next few days?
- JohnK/Scott: yes, might have schema by
Thursday
- JohnK: Kerberos (line 3925)
- not all interested parties present
- principal authentication mechanism is
represented
- JohnL: confused by "Kerberos
Protected Transport"
- JohnK: was going to do this, but didn't,
so should just be
"Kerberos"
- Hal: thinks right way to do this is to
treat the initial
handshake (preauth, PKI, whatever) as a
property of Kerberos
- Scott: the other case was this web use
case, where principal
sends password to server, who happens to
use Kerberos to
verify it
- called
"PasswordProtectedTransport" (3819)
- don't want to confuse this with
"Kerberos"
- Jeff: suggests
"PasswordOverProtectedTransport", because
"PasswordProtectedTransport" is
misleading
- Frederick:
the old schema required authnMethod in authnStatement
- now AuthnContext is optional -- is this a
problem?
- Scott: could make it required
- also, none of the 1.0 URIs should be used
- JohnK: (line 4430) Secure Remote Password
modeled after Kerberos
class
- Rob: line 4429, parenthetical is confusing
- is reference to old value
- Scott: move to migration guide
- JohnK: SSL/TLS Certificate Based Client Authn
- Rob: same comment, move old URI to
migration guide
- JohnK: X509 Public Key
- Rob: mixture of old approach
("am" in URN) with new ("ac")
- JohnK: will strictly use new
- Frederick:
line 4539 has "WTLS", why?
- needs to be clarified
- JohnK: all of these public key methods are
very similar
- Scott: (line 4712) not sure what
XKMS has to do with user authn
- Irving: could be relevant as revokation check
- but that seems to belong inside
X509 class
- Scott: slippery slope, having this
as its own class
- resolution is to drop it as a
class
- Rob: add to migration doc
- Jeff: suggests that we maintain an
issues list for authn context
- we want to get doc out the door,
but we don't want to lose
issues for future work
- Rob: we can track in current
issues doc
- [ISSUE] Deprecation/removal of
XKMS authn context class
- Paul: prefers something other than
"keyAuthn" (ex line 4817)
in all public key classes
- group prefers "keyValidation"
- Rob: Table of Contents needs to be regen'ed
Spec Review: Authn Context,
Metadata, Profile (cont)
- Scott: walking thru Metadata doc (draft 06, PDF)
- changes
- mainly reformatted doc to match
template
- made some changes for uniformity
- not many others
- Version in EndpointType (line 165)
- profiles have changed in 2.0, so they're
really the first
version of their respective forms
- Irving:
suggests Major/Minor, like in core, if semantics
are the same
- Scott: still thinking on what Version means in
this context
- we've never versioned a profile before
- [ISSUE] Versioning in Profiles and Metadata
- Scott: has considered moving away from
element-based
approach to metadata, in favor of
attribute-based
- but makes XPath searching more complicated
- Jeff: solution could be to have separate
element for each
profile supported, and to include Version info
if relevant
- Scott: "families" of profiles will
be seen in Profiles doc
- [discussion ...]
- [resolution] drop Version, and any subsequent
versions of
profiles will result in new metadata elements
- e.g., if we create V2 of SingleLogout profile,
we'll either
create a new SingleLogoutV2 element in
existing metadata
namespace, or create new metadata namespace
- issue still open regarding versioning profiles
- continuing with Section 2.3 Root Elements
- <EntitiesDescriptor> is just a container
- <EntityDescriptor> is really the unit of
metadata
- beneath that, can have either
AffiliationDescriptor or (more
commonly) a sequence of one or more RoleDescriptor
(or a
derivation)
- AdditionalMetadataLocation allows implementations
that support
both ID-FF and SAML 2 metadata to publish both
forms, cross-
linked
- really, is a form of versioning
- [ISSUE] How to represent support for attribute
profiles in
metadata
- Scott: on SP side, added attribute indicating
desire to have
assertions signed by IDP, independent of profile
requirements
- Conor: what about on IDP side, stating that
assertions will be
signed?
- Scott: didn't do that, but can
- Prateek: more generally, can't endpoints have way
to state what
optional features they need or will provide?
- Scott: will require more thinking
- Conor: difference between what is wanted vs what
is accepted
- Scott: the reason signing got special attention is
overhead,
moreso than security
- KeyDescriptor (line 503)
- Scott: recollection is that EncryptionMethod
speaks to
encryption OF the key rather than encryption
BY the key (which
is why it states it in the doc), but needs to
verify
- [ISSUE] Verify purpose of EncryptionMethod in
KeyDescriptor in
metadata
- SSODescriptorType (line 536)
- Scott: "ArtifactLookupService" doesn't
sound right
- "ArtifactResolverService"?
"...Dereference..."?
- needs to be consistent with related protocol
components
- winner: ArtifactResolverService / ArtifactResolve
/
ArtifactResolveResponse
- [ISSUE] AssertionConsumerService ID attribute is a
string, but attr
name suggests xsd:ID type
- change to "Index"?
- Indexes are usually thought of as numbers
- can restrict values to be numeric
- [RESOLVED]
- [OLD ISSUE] some wanted to add location hinting to
artifact, to
support multiple artifact resolvers
- ArtifactResolverService will resemble
AssertionConsumerService,
including Index
- Artifact format will include space for this Index
- [RESOLVED]
- [ISSUE] SSO profile is different in how role division
is split
across request response
- In other profiles, request and response were
combined
- doesn't think it's a problem, it's just
different
- [ISSUE] SSODescriptorType shouldn't be a base
- Scott: how about eliminating the type, and move
the components
into SP and IDP descriptors?
- Jeff: we need to determine what
must be changed now vs. what
can we live with for now and
publish
- Rob: could rename SP and IDP descriptors
to SPSSO... and
IDPSSO...
- Scott: agreed
- Scott: continuing with
AttributeRequesterDescriptor (line 712)
- the IsRequired attr inside
RequestedAttribute allows the
expression of necessary attrs in SSO
- If we add indexes to
AttributeRequestingService, you can provide
a reference into metadata from attribute
queries
- AttributeRequestingService was previously
called
AttributeConsumerService, and someone
specifically asked for
name change
- Scott: dislikes "Service" in
"AttributeRequestingService"
- [ISSUE] Need new name for
AttributeRequestingService
[Paul Madsen taking over minute-taking]
June 15, 2:45 - 5:00, Minutes
---------------------------------------------------------------------------
Metadata tail-end
John Linn raises concerns about the complexity of some of
the metadata mechanisms.
Scott asserteed that it was in there becausee Neeustar has
implemented it and they need it in.
Need to make sure that text makes clear that this is
optional.
Jahan - I had thought we had decided to forgo the DNS stuff
Scott - we did, but a member pushed back.
[ACTION] Scott to ping Peter for additional text, subsequent
to that there will need to be a review to ensure that the appropriate SHOULDs
etc are there.
[ACTION] Scott to reorganize section 4 to clarify
Section 3 – Signatures
Scott suggests that we create a profile of XML-Sig for
signing metadata elements. might just be stating that you're signing one of
these three elements etc
---------------------------------------------------------------------------
SAML 2 Schedule
June 15: V2.0 F2F in Toronto
June 22: Review updates since f2f.
June 29: Both Prateek and I will be out – anyone want
a focus call this week?
July 6: All specification suite documents must have
incorporated all input from the list and F2F #5. Note that this gives us 3
weeks since the F2F to complete all document changes and to resolve issues and
action items. This now begins sort of a pre-last-call deadline for final
input. Depending on how well things come together, we might possibly start our
TC last call here, but we opted to allow another week before doing that.
July 13: VOTE to start 2-week committee last call period
(includes external public review).
July 20: Review any last call input to date.
July 27: Cut-off date for TC last call input. All
outstanding issues have been dealt with according to the last call process. The
specs now become our "candidate” Committee Drafts and the TC
addresses any outstanding non-normative editorial issues
August 3: VOTE to move spec’s to “Committee
Draft” status (requires YES votes from 2/3 of ALL voting members). VOTE
to move CD spec’s into 30-day Public Review for OASIS standardization
(majority vote). Edit doc’s for CD status. Notify TC admin of the start
of formal Public Review.
September 7 (first call following 30-day public review): Make
sure all public review comments have been properly dispatched. Final editorial
changes must be complete. VOTE to re-approve spec’s as final Committee
Draft and VOTE to submit to OASIS for standardization.
September 8-15: Complete all submission paperwork. All
submissions for an October voting period must be complete by September 15.
Rob's biggest concerns are around outreach docs
---------------------------------------------------------------------------
Spec Review: Authn Context,
Metadata, Profile (cont)
Profiles Discussion
sstc-saml-profiles-2.0-draft-10-diff.pdf
To cover
-Attribute profiles
-Connecting to Metadata
---------------------------------------------------------------------------
Attribute Profiles
Prateek took us through the recent changes to the Profiles
doc docussed on Attributes.
A new section provides a set of guidelines for defining
attribute profiles as well as 3 three specific attributee profiles
1) Basic Attribute Profile
2) LDAP/X500
3) UUID
Jeff Hodges asked for clarification as to whether the
profiles was for the reequest/response or for the designator/values? Scott
suggested that using 'query' in the intro text on line 125 was misleading as it
implieed something to do with the request/reequest protocol - text should be
expressed instead in terms of attributedesignator and attribute.
Prateek suggested that the implication on AttributeeQuery
should be noted
John suggested that Seection 1.1 Profile Concepts should be
moved before Prateek's text and then refereenced.
[ACTION] - Scott to clean up the text around the different
types of profiles in Section 1.1
Section 7.1
Provides a checklist of items that MUST be addressed by each
attribute profile.
Frederick raised the
issue that SAML cares about case - can an attribute profile override that?
Consensus is yes, we are covered.
Scott says that bullet 2 within guidelines 'Unique URI to be
used for the NameFormat attribute of the <saml:AttributeDesignator>
element' - NameFormat is inappropriate. A profile may need an identifier but
should it go on the designator?
May suggest that we need an new element more at the protocol
element.
Resolution1 - we should retain NameFormat for its original
use.
Do we need to carry the profile name as part of the
attribute or attributedesignator? What is the unit at which it makes sense to
specify profile. Discussion as to the relevance of being ablee to specify
profile on specific attributes.
Conor - are we accounting for XML attributes? Yes.
Rob- propasal that we be able to describe profile at the
statement and query level.
[ACTION] - investigate profile designator for statement and
query - potentially allowing for endpoint metadata.
Scott asserts that agreeeing on what to go in
attributedesignator and attribute elements is a subset of a whole bunch of
things you have to come to an agreement upon for attribute sharing. Prateek
acknowledges this but questions whether we want to think about this right now.
Agreement.
Rick - two levels of profiles
Frederick - do these
guidelines belong in core? Rob, it belongs in profiles in that it constrains
functionality.
Basic Profile
Jeff - why does xsi:type neeed to be present? To know
whether its a datetime or string etc
Frederick - I had
thought we had deprecated Attribute queries? Authorization and frozen.
LDAP/X.500
Names constrained to come from URN oid namespace (following
Bob)
Scott - I pushed back originally on Bob's proposal. No
longer an issue.
John - any BER & DER issues? Section 7.3.3 says the
canonical representation is an octet sequence. Scott- this was not Bob's
intent.
So what should we do?
What did DSML do? NA.
[ACTION] - Scott to talk to RL Bob.
UUID Profile
Intent is that UUIDs occur as attribute names. Not so clear
whether there are values.
[ACTION] - Prateek to ping John for clarification.
---------------------------------------------------------------------------
XACML Profile
Led by Prateeek
Submission from XACML TC to add to attributee profile
section
'SAML Attribute Assertions may be used as input to
authorization decisions made according to the
OASIS eXtensible Access Control Markup Language (XACML)
standard specification [XACML]. Since
the SAML Attribute format differs from the XACML Attribute
format, there is a mapping that must be
performed. The OASIS XACML TC has defined a Profile for
doing this mapping [XACML-Profile], but
that Profile imposes constraints on the meta-data provided
with the SAML Attribute. This Profile
describes those meta-data constraints'
ACTION - Scott to incorporate into document. include
reeference to Appendix A.
ACTION - Need clarification as to what is the target
namespace for the DataType element?
Scott is conceerned that the profile doesn't say anything
about what can go in the XML instance. Hal doesn;t see it as a concern.
---------------------------------------------------------------------------
From: John Kemp []
Minutes 2004-06-16 (morning) SSTC F2F
-------------------------------------
Outreach documents:
Arch overview
-------------
summary of overview doc looked good.
some things missing
- use of queries
- federation + other protocol profiles (logout, RNI etc.)
- discussion of general background to saml (web services
work, ID-WSF,
WSS STP)
discussion of 11-20 differences as separate document instead
of as part
of overview - only a bulleted list
migration + what's new combined in document
exec overview targetted to journalists + CEO (Paul Madsen
volunteers to
take this document)
AI: Paul Madsen to take the exec overview document
rob: when can we get first draft of tech overview?
john hughes: 22nd July (JohnH is on vacation after)
hal: publish first detailed outline sooner
prateek: id-ff 1.2 arch overview could be used as source
document
conor: use as much as is useful - it was contributed work to
SSTC
JohnH: next version of ppt on 22nd June prior to call?
rob: discussion on schedule yesterday. these docs are not
part of core,
but want to put out as part of last call. doesn't look like
we can do
that. would hope to get them complete by august 3rd
johnh: if eve can tidy it up, august 3rd id do-able
rob: get normative spec. work done first.
jeffh: no need to release all together
paulm: exec overview draft next week
frederick: are we
doing weekly "official" meetings?
rob: start in july, but prateek and i on holiday. need a
substitute chair
hal: should definitely do the meeting with substitute chair
jeffh: eve and/or i can do this. official business could be
done first,
and then focus on technical issues
rob: prateek and i will figure it out offline
implementation guidelines
-------------------------
charles: use ID-FF guidelines
johnk: a lot of mobile specific guidance
prateek: should add enterprise guidance, i'll be happy to
review
hal: cumulative knowledge
johnk: need to point to impl guidelines on website too, to
allow quick
updates
discussion of use of saml-dev list members or adding a wiki
AI: Scott will investigate use of wiki on Oasis site
rob: when can we get first draft?
charles: end of july...
migration doc (scott, prateek)
------------------------------
scott: very busy, won't get to it until late july, early
august
prateek: also busy
scott: will happen somewhat organically in liberty
rob: (reviews schedule) we require attestations before
august 3rd
prateek: "attestations" by some definition...
rob: talk about attestation process
hal: issue is granularity. doing every combination will not
fly.
rob: we're not doing implementation yet
hal: points out ability to waffle
scott: don't need to cover the whole spec. we required 3
doing each
piece of the spec. in 1.1
hal: definition is loose enough to lower the bar
rob: but is anyone actually going to do this?
jeffh: sun may attest, but depends on where we set the bar
scott: should agree on an errata process. just want to be
able to fix
the spec. don't know oasis rules.
rob: no Oasis errata guidelines - may not modify spec. till
public
review is done
jeffh: but should not be known flaws in spec. when go public
hal: oasis did not ack.
AI: chairs to put item regarding errata process on the
concall agenda
hal: recommends XACML errata process
rob: (break?)
prateek: should discuss attribute profiles GUIDs afterwards
-- break
Back to profiles discussion:
prateek: start with attribute profiles
irving: is anyone
still dialled in?
johnh: yes
johnh: want to be able to transport PAC (or parts thereof)
in SAML
attrib stmt.
prateek: these are GUIDs, right?
johnh: (explains DCE use of GUID, friendly name)
prateek: we understand
johnh: not seen the ability to do this in the specs.
prateek: optional XML attrib for friendly name. we struggle
with the
attrib value - is there one?
johnh: repeats use-case
prateek: all of that is captured in attrib designator
scott: trying to understand what the value is
johnh: value is GUID
scott: profile is "backwards"
hal: well-known uuid that represents Principal?
prateek: summary - name is UUID, value is also UUID
johnl: line 907 - dashes - is this a common way to represent
UUID as URI?
prateek: we need a normative ref to UUID as URI syntax
scott: uuid as uri sidesteps some of the punctuation issues
rob: would that be acceptable (UUID as URI)?
johnh: these are just nasty unreadable strings
irving: that's why
we need a more "readable" form for SAML attribute
usage of UUIDs
(discussion of what to reference)
johnh: that would be acceptable
AI: (Jeffh) Resolve status of RFC
scott: more concerned about what it is we're trying to do
here. all
attribs in PAC must have an value associated with the name.
(walks
through his understanding of the profile)
hal: it's little more complex.
johnh: extended PAC is more complicated, but we really need
only a
subset. You'll have only a single instance of a Principal.
we just want
to carry the UUID+friendly name of Principal + Principal's
group info
rob: can we do an example?
scott: (draws it) can we define a friendly name attrib in
the SAML
namespace?
hal: call it DCE name instead of friendly name?
scott: we already have a friendlyname attrib. so just use
that
--- example ---
<Attrib NameFormat="URI"
Name="urn:uuid:..." FriendlyName="Principal">
<attribValue
FriendlyName="(principal-name)">
urn:uuid:representing:dce_principal
</attribValue>
</Attrib>
--- end example ---
irving: if the
value has structure, structure should be represented in
value itself
conor: don't need to argue about element vs. attribute
irving: xml schema
makes representing such things difficult
(discussion of multiple lists of values mostly between hal
and conor)
rob: need to specify this in the profile - is name of
profile relevant
to profile?
scott: profile is addressing two things - primarily use of
UUIDs in
attrib values. The secondary purpose might be to call out
the
applicability of this to DCE use-case. No need to call out
that these
attribs are part of a PAC.
Don't want to standardize on friendly name
format.
hal: should document the well-known formats for attribute
name. there's
a short list
AI: (Scott) to document the well-known values for the DCE
attribute name
scott: silly to add sub-element to attribute value when we
already have
a structur efor this
(discussion of XML attribute values)
rob: leave it to profile
johnh: (signs off)
irving: anyone
dialled in?
(no answer)
PKI Cross-domain profile
(pki-cross-domain-profile-draft-01.doc)
---------------------------------------
rick randall: (introduces himself)
rickr: profile user is a large gov't agency interested in
SAML
rickr: (explains use-case)
rob: want to exchange attributes to allow authz
rickr: subject name is carried, they want xml encryption +
signature
hal: are they using public keys for subject confirmation?
hal: info about subject could be obtained from cert.
rob: in the PKI environment - there is one domain issuing
certs for its
users. Other domain issues certs for its own users. There is
mutual auth
between domains, but one domain doesn't know the other's
users
scott: grid community has same use-case
rickr: (explains profile)
rickr: auth over client-auth SSL
paulm: could be other type of cert-based auth
hal: doing exact match on subjectname of cert. query will require
encryption
prateek: is this the Shib use-case?
scott: yes, not necessarily doing client-auth
rob: and the grid...
scott: main issue is use of temp ID during auth exchange.
there is a
weak implicit presence proof. there is nothing that connects
the auth
exchange betwene the client and domain b and the attrib
query at domain
a. so, it's dependent on policy at domain a.
johnl: decision at domain a has nothing to do with user
presence +
confirmation
hal: this is not the issue - some people only want to
release info when
user is present. (gives example)
rob: no tie between the auth exchange and the attribute
release
scott: as long as authorities understand that there is no
ability to
determine user presence....
irving: fine for
this use-case, not so for other use-cases
rob: short-term identifiers cna be used to do this
rob: customer is not concerned about another random site
doing queries?
rickr: PKI trust is already established between domain a and
domain b
prateek: SAML 2.0 can model these flows
scott: we'd need to check the encryption requirements.
domain b can
encrypt keys for domain a.
scott: can sign the request, can pass the encrypted name
identifier, and
we support attribute encryption (as well as encrypting the
entire
assertion).
steve: subject is encrypted for different party
scott: encrypted thing is the subject of the query
hal: need to re-encrypt
scott: why?
(symmetric key is encrypted with public key of domain a)
hal: at minimum should use a different public key
irving: use a
"bulk key"
scott: why re-encrypt?
steve: sender needs to keep a copy of the blob.
(discussion of how to do this)
hal: you have to correlate these things. profile could say
that you
could just send the encrypted id back, or re-encrypt.
rob: we say it must be the same subject going back
scott: id must be identical
rob: what does exact match, "identical" mean in
this case? We should
clarify this
scott: encryption should not affect this equivalence - don't
mean to
preclude a name id being re-encrypted.
hal: one way to disambiguate is to differentiate name id
from encrypted
name id
AI: (Scott) Will fix spec. to be more precise about use of
encryption
with name identifiers.
Steve: profiles should say something about this - for this
one, profile
should state that either the name identifier will come back
with same
encryption, could be multicast encrypted, or re-encrypted by
domain b.
prateek: this use-case is covered
irving: no need to
make changes to core spec.
prateek: what is the status of this profile? we can meet
your requirements?
irving: do you
want this to be an OASIS SSTC standard profile?
rickr: yes. they want to do a procurement, and want a
specification to
point to.
irving: need to
comply with IPR policy
prateek: already done.
FORMALLY: Rick (and customer) should read and accept the
OASIS IPR policy.
rob: (explains IP policy)
rickr: willing to accept now
scott: reads text to meet previous AI
rob: need to see it written down
prateek: rick should send an email making a patent
disclosure to TC
mailing list
prateek: does this have to be a 2.0 work item?
irving: initial
submission asks for it to be part of 2.0 spec. set.
Alternative is to make a separate document to decouple from
current
release schedule.
mikem: two months ago, we closed for new work items
irving: agrees,
leaves the alternative open - separate document on a
different timeline
jeffh: this raises the SAML versioning issue again
(versioning discussion)
paulm: if just a resource issue, then i would be happy to
help get this
work done in saml 2.0 timeframe
hal: goal is to have something official out of oasis as soon
as possible
(discussion of the cut-off date)
irving:
(re-iterates point of cut-off date)
prateek: (summarizes)
(group discussion of profile name)
hal: if you give a general name, there will be pressure to
generalize
the profile
scott: should be fairly general
prateek: is there an issue?
hal: no well-formed profile yet
prateek: what instruction are we giving?
group: new ref of draft incorporating comments received
today
scott: if goal is just product conformance, then conformance
would be at
product level, and profile would be quite general.
irving: spec. will
have MAYs, but RFP will say MUST
rickr: customer wants profile to be more stringent
prateek: agrees that we should work this out within the TC,
rather than
leaving it to RFPs etc.
irving: perhaps
have two sub-profiles?
scott: seems like a missed opportunity if we write the
profile too narrowly
rickr: (lays cards on table) would very much like to include
this
profile in main profiles document, and explains reasoning
hal: maybe we should reconsider the cut-off date, if we have
a full
profile document
conor: acceptance for what you want to do, it's just a
question of timing
scott: look at SSO profile for example (and explains how to
reference
other profiles)
(group) profile can treate domain b auth server at domain b
destination
web site as same entity for purposes of profile. (if you
don't want to
use custom product for destination web site)
rob: other questions?
rickr: what happens after new version of profile?
rob: (explains process) we'll discuss this on a call
steve: any general disposition on profiles?
AI: (chairs) discuss + resolve general approach to new
profiles
rob: do rest of profiles document after lunch
scott: want to leave with a good idea of what profiles need
to be in the
document
prateek: modify schedule to do profiles next, instead of
conformance
rob: (modifies schedule, adjourn for lunch)
-- lunch --
From: Charles Knouse []
June 16, 2004 afternoon
PROFILES (Scott)
Section 4.1.6 Use of Metadata
Discussion of coupling of profiles with metadata.
Prateek: How does metadata coupling show up in conformance?
Scott: Intent not to require use of metadata to configure
implementation; but if using, then conform to normative rules for use.
Section 4.1.4.3
"Security context SHOULD be discarded once
SessionNotOnOrAfter reached".
Discussion of what security context is. "derived from
assertion",
ACTION ITEM: Jeff to add security context to Glossary.
Should be SHOULD or MUST? MUST in ID-FF. Leave as SHOULD;
explain implications in Implementation Guidelines.
Scott: Profiles to be done
1. Single Logout
2. NameID Management
3. Authn Query
4. Attribute Query
5. Authz Query
6. Assertion Request
7. Artifact Resolution
Only profile 3-7 for synchronous exchange (e.g. SOAP
binding)
What is Authn Query for? Rob has seen use case.
Should 1, 2 be pair of profiles for front channel and back
channel? optional vs. mandatory for conformance. Conclusion: single profile.
Profiles that are done: Browser SSO, NameID mapping, ECP SSO
Sections:
Single Signon Profiles: Browser SSO. ECP SSO, Single
Logout
Queries: Authn, Attribute, Authz
NameID Management
AssertionID Request
Artifact Resolution
ACTION ITEM: Jeff to help with sequence diagrams for
profiles.
-----------------
CONFORMANCE (Prateek)
Scott: Should change Response to AuthnResponse, since every
one keeps using that? no
SAML Core message formats e.g.
AuthnRequest
Response
Bindings:
HTTP Redirect
Form Post
HTTP Artifact
HTTP URI
SOAP
PAOS
Messages over bindings, e.g.
HTTP-Redirect(<AuthnRequest>)
SOAP(<AttributeQuery>)
Profiles, e.g.
Browser SSO
ECP
Logout
NameID Management
Roles
IdP
SP
Conformance statement: e.g.
Product in role IdP implements Browser SSO profile
consumes HTTP-Redirect(<AuthnRequest>)
responds Form Post(<Response>)
Scott: SOAP has additional interop requirements, e.g.
security, which metadata does not cover.
How granular should conformance statements be?
Too fine grain has negative impact for marketing.
Precise product specification vs. mandatory to implement
Need term from claims of support; want to use same language
for conformance statements
Hierarchical approach: higher level for marketing, lower for
product specs
General agreement that SSTC needs to define the language,
else someone will.
Proposal for course grain conformance matrix
IdP
SP
Web Browser SSO and logout
Name ID mapping and management
Mobile device
Assertion query/request
Scott: lumping queries together a mistake.
Frederick: mobile
device seems different than other functional categories
Conor: good for implementers, doesn't solve deployers needs
Prateek: conformance for vendors, not deployers
Irving: only half
true; deployers need to worry about federation between vendors
Jeff: approach worthwhile, may disagree with individual
categories; Liberty
made all options mandatory
Scott: Liberty
products interop in wide range of environments because they implement all
options
Prateek: As ISV, sees Liberty
conformance matrix as serious barrier to implementation
Scott: Likes Liberty
definitions of IdP-Basic and IdP-Extended
Frederick: two
levels: marketing, technical
Conor: list of all possible knobs in SAML (!)
Jeff: to make workable, not a lot of options in rows
Scott: in Liberty
matrix, basic, extended along columns, not rows
Conor: battle in Liberty
over which requirements get support; push to not separate functionality
Scott: Liberty
conformance by column roles
Displayed Liberty
profile matrix (liberty-idff-1.2-scr1.0):
rows: features (e.g. SSO using Artifact Profile)
columns: roles (IDP, SP Basic, SP, LECP)
cells: MUST, OPTIONAL, blank
Jeff: Prateek proposing unit of conformance is a cell, Liberty unit of
conformance is a column. From experience, conformance across rows useful.
Scott: tool for combinatorial explosion of profiles x
messages x bindings
Scott: no MUSTs in Liberty
for security requirements like signing vs. TLS.
ACTION ITEM: Rob to enumerate the implementation
declarations/claims of interest. Prateek and Scott will contribute.
Darren: agrees with new format and agrees need more
granularity than Liberty.
-----------------
ECP PROFILE (Scott)
SP uses PAOS; IdP uses SOAP
Flow
1. EC -> SP: HTTP Request + PAOS header
2. SP -> EC: PAOS(<AuthnRequest>) + PAOS
header + ECP header
3. EC -> IdP: SOAP(<AuthnRequest>)
4. IdP-> EC: SOAP(<Response>) + ECP header
5. EC -> SP: PAOS(<Response>)
6. SP -> EC: HTTP Response
Schema for ECP header goes into Core.
Frederick confirms
flow is correct.
-----------------
Spec Review: CORE draft-14
(Scott)
Subject Confirmation
Scott: Assigned own subsection and type used for derivation
in subsequent sections. Also common attributes
Scott: "Authenticating the subject" wrong?
Jeff and Frederick: line 587 "specifies a subject"
should be "provides a means for a relying part to verify the
correspondence of the subject of the assertion with the party with whom they
are communicating."
Scott: subsequent "authenticates" to be
"confirms".
Scott: IPAddress attribute take the place of
<SubjectLocality> for products that need the user agent address (e.g. to
stick in a cookie). Should remove <SubjectLocality>? No resolution yet
Frederick: Should
change "IPAddress" to "Address" for other types of
addresses.
Discussion between Rob and Scott on whether in the Artifact
profile, does the browser present the assertion to the SP?
Conor and Scott: In Artifact: browser presents assertion by
reference; In Post: browser presents assertion by value.
KeyInfoConfirmationDataType
Can hold multiple KeyInfos for multiple confirming entities.
Everything inside each KeyInfo must refer to the same key.
Can be used for impersonation.
AuthnMethod removed in favor of AuthnContext; AuthnContext
now required.
SessionIndex moved from Statement to AuthnQuery.
Cleaned up MUSTs for certain status codes.
Cleaned up name IDs to support encrypted IDs.
Removed authentication methods from Section 8.
Changed language in Section 8.4.7 Persistent Identifier to
be less specific. Prateek to review.
John Linn's issues (e-mail Monday June 7: comments on
sstc-saml-core-2.0-draft-14-diff.pdf)
Assertion ID uniqueness
OneTimeUse confusion:
Hal: intended for attributes and authz decisions;
doesn't know how this applies to authentication
John L: should tighten language to indicate this
Scott: Bob M. suggested text missing on what
NotBefore/NotOnOrAfter means for attributes.
ACTION ITEM: Hal will look at OneTimeUse text again and
attempt to clarify.
DNSAddress vs. DNSName
Security context needs to be in the Glossary.
ACTION ITEM: John K. to clarity text on 909-911 on
SessionIndex.
Steve: Why is SessionIndex required?
John K: For logout. If you don't care, can always be 0.
Conor: Does everyone support multiple simultaneous sessions?
ACTION ITEM: John K. to look up why SessionIndex is
required.
Discussion on what to do if signature verification fails?
Relying party SHOULD not rely on rely on assertion (!)
Scott: Nothing in spec that requires second level status
codes. Can add codes that can be used.
Implementations can have switch to report or suppress
secondary codes. Also can be logged.
-----------------
Spec Review: BINDINGS draft-12
(Scott)
Line 900: Artifact MessageHandle at least 16 (up from 8)
random bytes.
Scott: Planned to steal 2 bytes from MessageHandle to hint
on AssertionConsumer metadata.
Rob: If using SHA-1 hash for handle, need all 20 bytes.
Scott to look at this again.
Scott: security discussion in SOAP binding (sections
3.2.3.2, 3.2.3.3, 3.2.3.4) should be in conformance instead.
Hal: Should be option to use WSS.
Steve: Should call out several options MAY be used for
integrity and confidentiality.
General confusion and amazement about section 3.2.3.1 on
HTTP headers and caching.
Hal: Line 324 should declare the intention to not cache
response.
Prateek: Preceding Sections 3.2.2.3-3.2.2.5
(protocol-independent SOAP) refer to sections 3.2.3.2-3.2.3.4 (SOAP over HTTP).
ACTION ITEM: Scott to
propose alternate text for section 3.2.3.1
strike 3.2.3.2-3.2.3.4.
rewrite 3.2.2.3-3.2.2.5
Jeff: Some security choice needs to be mandatory to
implement, e.g. TLS.
Section 3.4.5.1: similar issues to section 3.2.3.1.
ACTION ITEM: Hal to get expert advice on how to prevent
caching by proxies and user agents.
John Linn's issues
Protecting association of RelayState with other SAML message
elements.
Does ID-FF Security Considerations document issue?
Need to say something in SSO profile and security
considerations about the issue.
-----------------
Spec Review: ISSUES
Because of lack of quorum, recommendations will be made for
resolution at the next quorum call.
CORE-7: SOAP Version in Protocol Binding
RECOMMENDATION: CLOSE. Leave binding at v1.1
CORE-9: Wildcarding and Extensibility in the SAML Schemas
Leave OPEN
CORE-12: Consider Changing Name Identifier Format Default
for Issuer
RECOMMENDATION: CLOSE. In prose, state the default is
"entity".
CORE-16: Inconsistent Naming
RECOMMENDATION: CLOSE. Make "Reference" to
"Ref" change.
CORE-22:URIs vs.Prefixed QNames in Status Codes
RECOMMENDATION: CLOSE. Scott to rework specs to use URIs as
appropriate.
CORE-25: Require SessionIndex on LogoutRequest
RECOMMENDATION: CLOSE. Scott to update prose to explain why
not required.
CORE-27: Consider Limiting Datatype of Attribute Name
Leave OPEN
BIND-3: Establish a Mandatory Profile
Leave OPEN.
TECH-1: Identity/Service Provider Terminology and Domain
Model
Leave OPEN.
TECH-3: Impersonation Using SubjectConfirmation and KeyInfo
RECOMMENDATION: CLOSE. Check with Ron if HolderOfKey issue
resolved.
TECH-4: Glossary Additions: Artifact, Binding, Profile
Leave OPEN until associated action item is done.
TECH-5 Improve Federation Terminology
Leave OPEN until associated action item is done
TECH-6 Highlight Privacy Considerations
Leave OPEN.
TECH-7 Add/Correct Instance Examples
Leave OPEN.
From: Jeff Hodges []
Sent: Friday, June 18, 2004 12:13 PM
To: Prateek Mishra; Robert Philpott
Cc: ; Eve L. Maler
Subject: raw notes from Thur 17-Jun Toronto F2F
--------------------------------------------------
Thur Morn – Jeff Hodges
17-Jun-2004
Fredrick Hirsch -- Sec & Privacy issues
going thru changes to latest rev of the doc
intends to ref other docs eg Lib Sec & Priv Guidelines
Hal notes that there may be other orgs that are
privacy-centric that
have docs we may want to also ref
notes that achieving privacy isn't necessarily simple or
a clear
goal in itself
so upshot is that we probably want to catagorize the SAML
features that
can be used in crafting some notion of privacy in addn to
ref'g the
other docs
Fredr still needs to insert the profile-specific sec cons
from the
SAMLv1.1 prof spec
Fredr commenting on the addn's to the doc..
binding of identity to key -- clarified notions
[various detailed review comment ensued where Fredr
maintained
his own detailed notes]
scott will have suggestions about URI bindings
kemp: can we update the ref to "reliable
messaging" stuff?
fredr: concurs
--------------------------
[capture my update wrt app/saml+xml MIME media type
registration]
draft-hodges-saml-mediatype-00 has been pub'd as an
Internet-draft.
sent it to for review.
Graham Klyne sez it is "looking fine" to him
modulo the "and/or" cite (in the
sec cons section) of diff versions of SAML.
draft-hodges-saml-mediatype-01 will be pub'd soon -- only
diff is that it will
be rfc3667/8-compliant.
so reg of application/saml+xml is in the pipeline and the
stake-in-the-ground
has been publicly set.
so in our samlv2 spec, in the one (we believe) place where
this media type is
mentioned, the worst case we will have to do for final
samlv2 specs in the fall
is to say something like..
official IANA reg of application/saml+xml is pending, see
[draft-hodges-saml-mediatype-xx] (informative reference).
in the meantime
implementors and deployers SHOULD use
"x-application/saml+xml" until
said reg is accomplished and
[draft-hodges-saml-mediatype-xx] is
pub'd as an RFC.
---------------------------
Review of...
Security Analysis of the SAMLS SSO Browser/Artifact
Profile
Thomas Gross
6.1 Step 1
prateek: this step is actually out-of-scope of the pub'd
SAML spec
ie. the UA determining that the "source" site
is indeed the expected/
desired source site is out-of-scope of the pub'd
sAML spec
this is a reasonable comment technically.
scott: however the author presented the above as if it
*is* a portion
of the spec and thus the paper is arguably misleading
[ the paper says "In the first protocol
step,...", but the paper's
step 1 is *not* normatively specified in the SAML spec ]
wrt "msg format attack" -- this is an attack on
HTTP in general in that
parties may attach any amounht of gunk to a URL and it
also refers to
repetition of some steps that are not ... it is not
clear...
hal: every http msg is subject to this attack, so it
isn't particular
to saml
"user tracking" subsection in section 6.1 of
the paper refers to an
issue that is out-of-scope for SAML and is not required
in any SAML
prot step
6.2 Initiating the Redirect to the Destination Site
scott: uncomfortable with the discussion of relating the
artifact url
to the destination site.
the author is apparently loosing the context that there
is a seperate
base of knowledge that a given "assn consumer
svc" and a given
"dest site" is linked. without that knowledge
one can hand an artifact
to the wrong party
prateek & Hal: but that isn't a viable threat because
just obtaining an
artifact is not necessarily a concrete threat in the
overall scenario --
one may not be able to dereference it and so it is
worthless.
6.3 Step 3: Redirect to dest site
wrt "lack of authn" para, the bindings spec
does indeed specify using TLS
as a SHOULD
thus it is a misleading claim to imply that the spec does
not specify
authn at this point.
6.4 Step 4: SAML Request
wrt "specification of the source site lookup"
para: the author is
apparently mislead by the wording in the saml bindings
spec, or that
his point is that the spec doesn't make things
sufficiently clear here.
however, in line 541 & 542 of samlv1.1 bindings spec,
we do specify a
a MUST for bilateral authn.
prateek: thus the author is saying that the bindings spec
is not
sufficiently clear that the source site needs to pay
attention to
*who* is authn'g and def'g an artifact. ie it needs to
apply some
policy.
rob: in bindings 1.1 line 579 notes that the source id
is used to
determine source site *identity* as well as location,
thus the author
is in error.
line 551 in the 1.0 bindings spec.
wrt "one-request property of the SAML artifact"
para:
prateek: artifacts are explicitly specified as being
short-lived.
scottc: tho the author's right about that there being an
attack where an
attacker may capture an artifact being retgurned from
the source site
to the UA and then front-run the UA and present it to
the dest site
and thus impersonate the UA.
6.5 Step 5: SAML Response
wrt "one-req property of the saml artifact"
para:
scottc: author is saying that this property is hard to
impl
Hal: author is saying that "simple things are
easier to make secure,
and here's a complex thing"
fredr & scott: this is a good catch, in actuality
prateek: so we should spec in samlv2 that dest sites as
well as source
sites should enforce the one-time use of artifacts.
all: yes.
wrt "multiple services on one host" para:
scott: author is claiming that because the sec is
host-name-based
(which is false), then ...
but the granularity is "destination 'site' "
where a dest site can
well be mapped to specific sec credentials, and one can
host mult such
sites on a given web server.
hal: author's prob rite...
scott: the host-named-based claim made by the first
sentence in this
para is fundamentally misleading.
prateek: so the way we should reply to this is that this
is broken in
the paper, but that yes, we need to make the samlv2
spec more clear
about the various means available to the source and
dest sites to
identify each other and recommend strong means as
appropriate.
6.6 step 6: response to the browser
wrt "specification of this step" para:
scott: note the sentence "We also assume that it
has the same sec props
as in step 3." which implies that there's no
security becuz that was
the author's claim back on step 3.
thus we rebut step 3 and thus we should rebut here.
wrt "HTTP referrer tag" para:
scott: this is a good catch.
in samlv2, our specifying the dest site maintaining
state mitigates this
also, delivering artifact via POST eliminates it
prateek: concurs
7. Attacks
7.1 connectino hijacking / replay attack
wrt "possible solution" para:
prateek: the spec strongly encourages the use of TLS,
and if so used,
this is moot.
7.2 MITM attack
7.2.1
prateek: even tho it is out-of-scope, we'll add lang to
samlv2, that you
shouldn't give yer id & pswd to a site wihtout
authn'g the site first
ie. the author simply identified "phishing" as
a threat, which is a
known issue wiht the web and endemic to it.
7.2.2. other MITM attacks
scott: the prob here is the sentence " as the saml
sso prot specs no
security props for this step 0, we can assume that the
connectioon is
unsecured"
prateek: the resp to this is that indeed use of TLS is
recommended.
7.3 http referrer attack
prateek: first point of rebut is that TLS is indeed
rcmd'd in spec
scnd point - yes we should mention use of some sort of
referral clearing
3d pt - is that in samlv2 we'll ahve the artifact POST'g
8. Vulnerability of the SSL/TLS Binding
scott: mid of para 2, there's some miss-statements, aka
wrong, things
9. conclusion
johnl: if you assume that saml is deployed in an environ
with no TLS, then
yes, there are design issues with saml. but the domain
of applicability
of SAML is wider than that.
-----
prateek: am looking for an owner for someone to take the
above and start a
document
johnl: will work with prateek to draft it up.
AI: johnl and prateek to draft up a document commenting on,
acknowledging, and
clarifying certain points in the IBM Research Report RZ 3501
(# 99427) 06/30/03
----------------------------------
working on the conformance spreadsheet
longish not-terribly-conclusive discussion about what it
means to
"support the metadata spec"
scott: a tentative suggestion was made that mebbe we want
to try to
somehow make the use of particular elemens requiring the
use of
metadata easier to use in the case where one is not
actually
using the metadata spec.
recommendation: make spec set more generic where it
referes to
metadata, make guidelines for creating new profiles be
more specific
wrt needing to spec needed metadata.
--------------------
the TC formally thanks Irving
for hosting the meeting!!
adjourned.
============================================================================
← Prev in month
← Prev in thread
Next in thread →
Next in month →