OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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

Subject: [no subject]

List of "small issues" to discuss from white board (collected during the 

Encryption key dist (1 or more) + "recipient"
DoNotCache - Why?
Privacy Considerations
Authn Cntx (stmt, decl, claim,....}?
Authn Method?
Schema extensibility
any Attribute - evil?
"SAML Authority == IDP"?
Domain Model
Consent vs Reason
Element vs Attribute review
QName prefixes in status

Session closed at 5:15
--=_alternative 007FD2EB85256E67_=
Content-Type: text/html; charset="US-ASCII"

<br><font size=2><tt><b>Review/approve core draft-04 thru draft-08 changes
continued (from morning session)</b></tt></font>
<br><font size=2><tt>Eve has published sstc-saml-core-2[1].0-draft-08-diff-from-04</tt></font>
<br><font size=2><tt><b>&nbsp;</b></tt></font>
<br><font size=2><tt><b>3.5 Artifact Protocol</b></tt></font>
<br><font size=2><tt><b>3.5.1 ArtifactRequest</b></tt></font>
<br><font size=2><tt>Scott: deliver a message by value rather than by reference.
<br><font size=2><tt>Protocol should be done in an authenticated manner.
<br><font size=2><tt>This describes protocol for doing dereferencing. </tt></font>
<br><font size=2><tt><b>3.5.2 ArtifactResponse</b></tt></font>
<br><font size=2><tt>Scott: Old model, sending more than one assertion,
multiple artifacts. This change lets you return one artifact tied to the
response. <br>
Conor: Use case on request: HTTP redirect </tt></font>
<br><font size=2><tt>Scott: before never had request only request/response
or response</tt></font>
<br><font size=2><tt>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.</tt></font>
<br><font size=2><tt>Conor: Can see a use case where artifact is only used
on one side</tt></font>
<br><font size=2><tt>Scott: Trying to make a general use case and not create
special features. </tt></font>
<br><font size=2><tt>Scott: Make passing of messages independent of messages.
Try to eliminate Post and Artifact Profiles. </tt></font>
<br><font size=2><tt>Tim: How to handle case where response does not come
<br><font size=2><tt>Scott: Not specific to artifact discussion</tt></font>
<br><font size=2><tt>&nbsp;</tt></font>
<br><font size=2><tt>Prateek: Should we sign or authenticate?</tt></font>
<br><font size=2><tt>Scott: Common language on all protocol messages.</tt></font>
<br><font size=2><tt>Prateek: Concerned about text on line 2118 &quot;...SHOULD
be signed or otherwise authenticated....&quot;</tt></font>
<br><font size=2><tt>Scott: Not a MUST, need to provide some recommendation
to protect message. </tt></font>
<br><font size=2><tt>Eve: this is boiler plate text for all messages. Need
to agree on the correct text for this. </tt></font>
<br><font size=2><tt>RL Bob: Telling people who are writing bindings what
they should say</tt></font>
<br><font size=2><tt>Scott: Also message to developers</tt></font>
<br><font size=2><tt>Prateek: does this disallow case when you send message
over HTTP</tt></font>
<br><font size=2><tt>Scott: It's a SHOULD (MAY would be too weak)</tt></font>
<br><font size=2><tt>Eve: Would a reference to bindings document help?</tt></font>
<br><font size=2><tt>Scott: In old protocol, signing was not wanted. Needed
to authenticate both parties.</tt></font>
<br><font size=2><tt>Eve: #any should be ##any</tt></font>
<br><font size=2><tt>John Kemp: Misleading that &quot;any&quot; is used
(not necessarily dangerous)</tt></font>
<br><font size=2><tt>Eve: Need to constrain wild cards (any). Need to add
prose to define what is expected. </tt></font>
<br><font size=2><tt>Conor: redirect is better user interface for users
on phones (need to consider this use case)</tt></font>
<br><font size=2><tt>Eve: Need to motivate generality</tt></font>
<br><font size=2><tt>Scott: Would need to define artifact processing for
5 profiles. </tt></font>
<br><font size=2><tt>John Linn: First reaction, nice generalization but
it's new and scary. Seems to be a natural set of generalization.</tt></font>
<br><font size=2><tt>Prateek: any profile that uses this would have to
verify its use. </tt></font>
<br><font size=2><tt>Scott: choice of what to use is deployment specific</tt></font>
<br><font size=2><tt>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. </tt></font>
<br><font size=2><tt>Scott: Implementers prefer generality.</tt></font>
<br><font size=2><tt>Eve: what do we say to implementers of 1.x? We have
allowed imbedding protocol message in a response.</tt></font>
<br><font size=2><tt>Eve: Can't know how we feel about this until we discuss
<br><font size=2><tt>Scott: Need to change text in bindings to match this.</tt></font>
<br><font size=2><tt>Frederick: Need to go back and ask question about
previous section on Authn request</tt></font>
<br><font size=2><tt>line 1628</tt></font>
<br><font size=2><tt>AssertionConsumerServiceURL</tt></font>
<br><font size=2><tt>Wording suggests it is used for only an error (this
seems too strong). </tt></font>
<br><font size=2><tt>ECP uses URL, not just for errors.<br>
Scott: It is used only for errors.</tt></font>
<br><font size=2><tt>Scott: What's written has to be weaken so it's not
limited just to errors (can see other uses for this). </tt></font>
<br><font size=2><tt><b>3.5.3 Processing Rules</b></tt></font>
<br><font size=2><tt>RL Bob: relationship between issuer and signer is
more restrictive here</tt></font>
<br><font size=2><tt>SAML in general says nothing (they can be anything)</tt></font>
<br><font size=2><tt>For these protocols need some rationality between
the relationship of issuer and signer. </tt></font>
<br><font size=2><tt>Irving: Could create a table that shows relationship
between issuer and signer. </tt></font>
<br><font size=2><tt>Scott: What to do when you have metadata about signer</tt></font>
<br><font size=2><tt>RL Bob: there will be many policies and need to validate
against policies</tt></font>
<br><font size=2><tt>scott: idff - tight relationship between metatdata,
signers and keys</tt></font>
<br><font size=2><tt>Conor: somewhere in the spec there has to be rules
for signatures. We could refer that section here. </tt></font>
<br><font size=2><tt>Irving: don't want to be specific here about policy
for validating signatures. A profile for idff can specify policy for validation.
<br><font size=2><tt>Rob: Can we remove the second sentence? (lines 2136-2138)</tt></font>
<br><font size=2><tt>Scott: We should be able to remove issuer all together</tt></font>
<br><font size=2><tt>Irving: In SAML 1.0 specifically separated signers
and issuers. </tt></font>
<br><font size=2><tt>Tony: The first sentence (line 2136) is too strong</tt></font>
<br><font size=2><tt>ACTION for RL Bob/Irving: Need to change the wording
for the first paragraph under section 3.5.3 Processing Rules.</tt></font>
<br><font size=2><tt>Tony: Don't want to have to validate all signatures
if more than one</tt></font>
<br><font size=2><tt>Scott: There will only be one (multiple signatures
might be possible later)</tt></font>
<br><font size=2><tt>Frederick: Can't you combine signature and TLS and
later decide not to validate signature because of transport over secure
channel. &nbsp;</tt></font>
<br><font size=2><tt>Scott: say nothing about signatures in any of the
individual protocols. Schema permits signing of messages for protocols
that do not provide integrity protection. </tt></font>
<br><font size=2><tt><b>3.6 Federated Name Registration Protocol</b></tt></font>
<br><font size=2><tt>Prateek: Has anyone deployed this protocol? Concerned
that this may be a niche protocol. </tt></font>
<br><font size=2><tt>Conor: From IDP side found this useful for consolidating
accounts. </tt></font>
<br><font size=2><tt>Scott: Get rid of restriction in red (line 2176) &quot;Only
federated identifiers.......can be replaced and set with this protocol....&quot;
Get rid of this text all together. </tt></font>
<br><font size=2><tt>Eve: Have to address notion that we have multiple
protocols now. </tt></font>
<br><font size=2><tt>Prateek: How to roll over persistent pseudonyms</tt></font>
<br><font size=2><tt>Prateek: IDP pushes out new proposed identifier, SP
pushes proposed identifiers to IDP (more challenging)</tt></font>
<br><font size=2><tt>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 obviscate
it in any way. </tt></font>
<br><font size=2><tt>Prateek: Still have concerns about implementability
and deployability. </tt></font>
<br><font size=2><tt>Eve: Need a conformance document story by next F2F</tt></font>
<br><font size=2><tt>Conor: older systems don't cross domain boundaries
but this is changing.</tt></font>
<br><font size=2><tt>Rob: Have to deal with attestations before we go to
standards bodies. Need implementations to justify all parts of the specs.
<br><font size=2><tt>Eve: Require 3 or more attestations for use of spec.
Conformance document should reflect lines numbers targeted for attestations
(implementations). </tt></font>
<br><font size=2><tt>Hal: Not all useful features will be implemented in
first versions of products. &nbsp;</tt></font>
<br><font size=2><tt>Conor: Use case, establish initial connection with
social security number and later change the ID to something not connected
to ss#</tt></font>
<br><font size=2><tt>Eve: OASIS requires some minimal community wants this
and some companies were able to implement. SAML usually has a higher bar
than this.</tt></font>
<br><font size=2><tt><b>3.7 Federation Termination Protocol</b></tt></font>
<br><font size=2><tt>Scott: Name is wrong. &quot;I am no longer going to
talk about John anymore&quot;</tt></font>
<br><font size=2><tt>RL Bob: Unregister Name Identifier (to match Register
<br><font size=2><tt>Scott: Change RegisterNameIdentifier to deregister
if no new name identifier is specified.</tt></font>
<br><font size=2><tt>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. </tt></font>
<br><font size=2><tt><b>Action for Scott:</b> propose change to RegisterNameIdentifier
to handle unregister case and consider specifying an attribute that identifies
intent of operation. </tt></font>
<br><font size=2><tt>&nbsp;</tt></font>
<br><font size=2><tt><b>3.8 Single Logout Protocol</b></tt></font>
<br><font size=2><tt>John Kemp: No change since last F2F. Only addition
was reason attribute. Reason for logout (previously proposed by Hal)</tt></font>
<br><font size=2><tt>Hal: Who is doing logout and why</tt></font>
<br><font size=2><tt>John Kemp: Still have questions on whether you want
to specify this information or not. </tt></font>
<br><font size=2><tt>Eve: It's only a string.</tt></font>
<br><font size=2><tt>John Kemp: Should be a URI (mistake)</tt></font>
<br><font size=2><tt>Eve: session index changed to element (not attribute)
is this correct? </tt></font>
<br><font size=2><tt>Conor: not attribute of Logout request (maybe this
should not be an attribute)</tt></font>
<br><font size=2><tt>John Kemp: this should be an element in this instance
(because not an attribute of logout request)</tt></font>
<br><font size=2><tt>Eve: throughout SAML need to examine style of attribute
versus element</tt></font>
<br><font size=2><tt>Conor: If SessionIndex is required in assertion request
than it should be required here. </tt></font>
<br><font size=2><tt>John Kemp: need to think about whether the above is
true or not. </tt></font>
<br><font size=2><tt><b>Action John Kemp:</b> Review the rational behind
<br><font size=2><tt>Conor: Only time you wouldn't include SessionIndex
is if there is no possibility of more than one session. </tt></font>
<br><font size=2><tt>Conor: Can you set an attribute to specify if no SessionIndex
than do a logout on all sessions. </tt></font>
<br><font size=2><tt>John Kemp: Need to add a reason attribute on logout
request to specify if user's credentials were compromised. </tt></font>
<br><font size=2><tt>&nbsp;</tt></font>
<br><font size=2><tt><b>3.9 Name Identifier Mapping Protocol</b></tt></font>
<br><font size=2><tt>Scott: Case where Name Identifiers are not globally
<br><font size=2><tt>Conor: RSA was asking for this. </tt></font>
<br><font size=2><tt>Prateek: Concerned about deployment and conformance.
What is the use case for this?</tt></font>
<br><font size=2><tt>Eve: What profiles use these new protocols?</tt></font>
<br><font size=2><tt>Scott: Do they need to be profiled? Is there another
generality that profiling is needed.</tt></font>
<br><font size=2><tt>Eve: Profiles are embodiment of use cases. </tt></font>
<br><font size=2><tt>Scott: Do we need to create profiles to talk about
protocols at a conformance level?</tt></font>
<br><font size=2><tt>John Kemp: Need to define relationships between protocols,
bindings and profiles. </tt></font>
<br><font size=2><tt>Eve: Issue - what protocols are reflected in profiles?</tt></font>
<br><font size=2><tt>Scott: A lot of work to create &quot;null&quot; profile
to hang conformance statements off. </tt></font>
<br><font size=2><tt>Eve: Can several protocols be combined into one profile?</tt></font>
<br><font size=2><tt>&nbsp;</tt></font>
<br><font size=2><tt><b>Section 5 </b></tt></font>
<br><font size=2><tt>Needs editorial work</tt></font>
<br><font size=2><tt><b>Document in general </b></tt></font>
<br><font size=2><tt>Conor: show examples of assertions in document?</tt></font>
<br><font size=2><tt>Eve: would also be good to show complete use cases
in implementation guide. </tt></font>
<br><font size=2><tt><br>
<b>3:00-3:15: Break</b></tt></font>
<br><font size=2><tt><b>Proposed solution for assertion-level subjects
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; (includes Subject-less assertions)</b><br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Thread begins with<br>
<br><font size=2><tt>Scott: Subject may be specified in a way that is not
consistent with SAML </tt></font>
<br><font size=2><tt>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. </tt></font>
<br><font size=2><tt>Conor: specified that subject is implied.</tt></font>
<br><font size=2><tt>Scott: Not legal to have nothing</tt></font>
<br><font size=2><tt>Scott: Lots of queries don't make sense without a
subject. </tt></font>
<br><font size=2><tt>Eve: Use framework to make security assertions (with
subjectless statements). SAML changed the way subjects are handled which
creates an issue for XACML use. </tt></font>
<br><font size=2><tt>Irving: Only profile assertions with subject information
for SAML (don't prevent some other group from using it without subjects)</tt></font>
<br><font size=2><tt>Conor: Can specify each statement in SAML requires
a subject. </tt></font>
<br><font size=2><tt>Scott: Too hard to create restrictions in schema (subject
required for SAML statements). Easier to express this in prose. </tt></font>
<br><font size=2><tt>Scott: don't want to create profiles to show information
in core (to show subjects). </tt></font>
<br><font size=2><tt>Hal: XACML wants to do authorization decisions correctly.
<br><font size=2><tt>Rob: SAML is an assertion framework. Others might
want to use the assertion framework. </tt></font>
<br><font size=2><tt>Conor: Summary: Ok with subjectless assertion, is
SAML we document in prose that subject is required, specified at core level
and not profile level. </tt></font>
<br><font size=2><tt><b>Action for Eve:</b> Optional subject implemented
in core spec prose. Schema shows that subject is optional.</tt></font>
<br><font size=2><tt>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.</tt></font>
<br><font size=2><tt>Making an explicit design decision that is not really
explicit on</tt></font>
<br><font size=2><tt>By choosing to add prose to core spec we're making
a stealth abstract profile (generic design decision) that applies to all
explicit profiles. </tt></font>
<br><font size=2><tt>Scott: data model(design) decision to require subjects
in all SAML statements. &nbsp;</tt></font>
<br><font size=2><tt>Frederick: need to understand a clear data model</tt></font>
<br><font size=2><tt><br>
<br><font size=2><tt>RL Bob: Do we need to protect a SAML message?</tt></font>
<br><font size=2><tt>Hal: Most common cases are transport security, SOAP
security or protecting assertion (encryption)</tt></font>
<br><font size=2><tt>Hal: Deliberately excluded all cases (encrypting any
bit). Looked for common cases. </tt></font>
<br><font size=2><tt>Conor: Can you make a statment that if you encrypt
one attribute then you will encrypt all attributes?</tt></font>
<br><font size=2><tt>Hal: Might not need to, an attribute might be a passwd
that needs confidentiality</tt></font>
<br><font size=2><tt>Hal: We can add other entities to be encrypted to
the list if there are reasonable use cases.</tt></font>
<br><font size=2><tt>Tim: Does proposal cover integrity protection?</tt></font>
<br><font size=2><tt>Irving: Currently can sign whole assertion, are there
use cases to sign parts?</tt></font>
<br><font size=2><tt>Scott: Encrypt content and leave element in tact or
encrypt the element and content. Scott specified encryption in a different
way than Hal did. </tt></font>
<br><font size=2><tt>Hal: Can use the method that Scott has used.</tt></font>
<br><font size=2><tt>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. </tt></font>
<br><font size=2><tt>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). </tt></font>
<br><font size=2><tt>Scott: Encrypt SAML attribute or SAML attribute value?
&nbsp;(Even though we are not encrypting a lot of that same information
on the query). </tt></font>
<br><font size=2><tt>Hal: If query is not encrypted then you are giving
information about the response.</tt></font>
<br><font size=2><tt>Hal: would encrypted data be stored in a database?
<br><font size=2><tt>Conor: In IDFF concern about leaking information across
<br><font size=2><tt>Hal: Summary: agreement to encrypt SAML Attribute
<br><font size=2><tt>Allow encryption of Assertion Statement, NameIdentifier
and Attribute Statement</tt></font>
<br><font size=2><tt>Need schema and some examples. </tt></font>
<br><font size=2><tt>Tony: Are you only proposing encrypting the whole
body? Does their need to be a schema change for use with WSS?</tt></font>
<br><font size=2><tt>Greg: Section 2.1.2 of XML Encryption spec. Describes
that if you encrypt an element the atrributes on that element are not encrypted.
<br><font size=2><tt>Irving: Need to make sure anyone who extends statement
should inherit the ability to encrypt the statement. </tt></font>
<br><font size=2><tt><b>Action on Hal:</b> revise proposal to include decisions
made here along with details on use cases.</tt></font>
<br><font size=2><tt><b>Action on Editors: </b>Produce spec text that adheres
to proposal for group review.</tt></font>
<br><font size=2><tt><b>Action on Hal:</b> Look at SOAP binding and make
sure hand waving on WS-Security works.</tt></font>
<br><font size=2><tt><b>From Small Issues list (see below)</b></tt></font>
<br><font size=2><tt><b>DoNotCache - Why?</b></tt></font>
<br><font size=2><tt>Hal: Way to say validity period once.</tt></font>
<br><font size=2><tt>Eve: could update the spec to show relationship to
validity period. </tt></font>
<br><font size=2><tt>Conor: 3 validity times are one issue and single use
is another issue.</tt></font>
<br><font size=2><tt>Conor: Need to say this is a one-time use token (and
time frames are still valid time frames).</tt></font>
<br><font size=2><tt>Hal: Advisory at best. PDP could look at how it made
the decision. </tt></font>
<br><font size=2><tt>Eve: Can we rename this to make it easier to understand
use? OneTimeUse?</tt></font>
<br><font size=2><tt>Scott: Binding Condition - carry restrictions / rules
based on particular binding. Message validity not assertion validity.</tt></font>
<br><font size=2><tt>Scott: Need 3 things: 1. Latest time to process assertion
in profile (message expiration). 2. Reauthenticate on or after. 3. Assertion
<br><font size=2><tt>Rob: May need other conditions besides validity period.
<br><font size=2><tt>Conor: Two time periods, Consumption time period and
data content validity. Need 3 time specifications to cover these 2 periods.
<br><font size=2><tt>Rob: Lifetime of use of the data in the statement
has to be tied to the statements not the assertion. </tt></font>
<br><font size=2><tt>Conor: Need to add reauthenticate on or after. </tt></font>
<br><font size=2><tt>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.
<br><font size=2><tt>Irving: Need tight validity interval to make sure
assertion is delivered to relying party in reasonable time. </tt></font>
<br><font size=2><tt><b>Action for group:</b> Scott made a concrete proposal.
Group needs to make comments on proposal.</tt></font>
<br><font size=2><tt>http://www.oasis-open.org/apps/org/workgroup/security/download.php/6123/sstc-cantor-profiles-draft-01.pdf
<br><font size=2><tt><br>
<b>List of &quot;small issues&quot; to discuss from white board (collected
during the day)</b></tt></font>
<br><font size=2><tt>Encryption key dist (1 or more) + &quot;recipient&quot;</tt></font>
<br><font size=2><tt>DoNotCache - Why?</tt></font>
<br><font size=2><tt>Privacy Considerations</tt></font>
<br><font size=2><tt>Authn Cntx (stmt, decl, claim,....}?</tt></font>
<br><font size=2><tt>Authn Method?</tt></font>
<br><font size=2><tt>Schema extensibility</tt></font>
<br><font size=2><tt>any Attribute - evil?</tt></font>
<br><font size=2><tt>&quot;SAML Authority == IDP&quot;?</tt></font>
<br><font size=2><tt>Domain Model</tt></font>
<br><font size=2><tt>Consent vs Reason</tt></font>
<br><font size=2><tt>Element vs Attribute review</tt></font>
<br><font size=2><tt>QName prefixes in status</tt></font>
<br><font size=2><tt>Session closed at 5:15</tt></font>
--=_alternative 007FD2EB85256E67_=--

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