[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: First meeting of the "Focus" team is Tuesday, 24 April
At 04:11 PM 4/23/01 -0400, Hal Lockhart wrote:
>Since the F2F minutes are not yet available, could you publish the raw list
>of issues for the benefit of those of us who spent more time talking than
>note taking. ;-)
Here are my very raw "open-mike" notes. Hope this will suffice as an agenda!
* * *
Open-Mike Issues collected 18 April 2001
Categorized and ranked
Process:
- ShouldWeDoSAML
- TCStructure
General approach:
- SimplifyFirst
- SpecifyBehaviorToo
- DesignTraceability
- NeedDependsOn
- NeedAudiences
- NeedAdvice
- LimitSubject
- PEPNeedsRoleInfo
- KeyDelInClaims
- ProtocolChoreography
- ProtocolRecommendations
- TCB
Scope and requirements:
- UserSessions
- UserSpecificContext
- SSONotEnough
- UC-5-03:PassThruAuthN
- NoPolicyAssertions
- OptionalSigAndEncryption
- R-Reference
- R-Enveloped
- R-Extensible
- StrengthenAddDeleteMod
- UC-2-01:AddPolicyAssertions
- UC-2-05
- UC-7-01:Enveloping
- UC-9-01:RuntimePrivacy
- UC-9-02:PrivacyStatement
- SAMLVersions
- XMLAssertionGenerality
- CertsVsPasswords
- PropagateIDAssertions
- UC-1-05:FirstContact
- PassportHailstorm
Design:
- IndexicalReferencesConsideredHarmful
- SubjectDefinition
- ObjectDefinition
- XMLEncoding
- URIsForAssertionIDs
- MessageMeaning
- AuthZ decisions (constraint: mindless PEP)
Ideas for tutorials:
- XML Signature
- General enveloped/enveloping idea
- XML Schema and Namespaces
- Versioning options
* * *
Open-Mike Issues collected 18 April 2001
Pass-thru authentication (Hal)
User sessions (Gil)
AuthZ decisions
Bob Blakley:
- SimplifyFirst: create a minimal SAML environment. There are entities
and authorities. There are assertions (in messages). There are requests
and responses. Assume no format/bandwidth limitations. Assume every
part of the system is trusted. All communications are asynchronous
request/response messages. We should define "Core SAML" spec and then
optimize/extend as necessary.
- OptionalSigAndEncryption
- NoPolicyAssertions
Raj Sodhi: pass
Jeff Hodges:
- Supports DarkNightOfTheSoul. Concentrate on a single administrative
domain first.
RLBob Morgan:
- SpecifyBehaviorToo: Agrees with Bob Blakley in
general. But disagrees with specifying just data
formats and not protocols. We do want to standardize
on the behavior of implementations. He represents the
"customer." LDAP is an example of not achieving
interoperability with interesting uses of LDAP.
Carlisle Adams: pass
Phill Hallam-Baker:
- Doesn't like active session closure. Happy to have authN data appear.
- IndexicalReferencesConsid eredHarmful: Concerned with taking a subset
of the issues. An assertion whose subject is the bearer ("indexical")
is dangerous; its semantics change in mid- air. It seems simple, but is
a big problem.
- SubjectDefinition, ObjectDefinition: How to specify the Principal
(subject)? How to specify the Resource (object)?
- You can't separate a policy statement from a decision.
- XMLEncoding: It needs to be reviewed by XML- knowledgeable people.
Brian Eisenberg: pass
Allen Brown: pass
Eve Maler:
- ReferenceSection: We need a bibliography editor and citation
guidelines
- R-Reference: (line 92 of reqs) What exactly does "reference" mean? Put
it in the Glossary, along with token and ticket.
- R-Enveloped: (lines 94-95 of reqs) Don't understand language. Want it
clarified.
- R-Extensible: (line 108 of reqs) Motivate "easy" extension better
- StrengthenAddDeleteMod: (line 135 of reqs) Make the
add/delete/modification non-goal stronger by deleting "need to".
- UC-2-01: AddPolicyAssertions
- UC-7-01:Enveloping
- UC-9-01:RuntimePrivacy
- UC-9-02: PrivacyStatement
- SAMLVersions: Need requirement on this?
- XMLAssertionGenerality: Prefer several more specific <Assertion>
structures.
- DesignTraceability: Connect the design to the terminology and
scenarios
- URIsForAssertionIDs: (line 380 of spec): Why use URIs for unique IDs?
Are fragment IDs allowed?
- MessageMeaning: (line 727 in spec): Discuss the message/package
question and how it relates to bindings. We need a whole lot more
terminology defined here.
Kelly Emo:
- Supports meta-issue of rationalizing the use cases and scenarios, the
domain model, and the design.
- Supports questioning the extensibility and versioning issues.
Gil Pilz:
- Is here to bury sessions, not to praise them. We haven't motivated
them very well.
- SSONotEnough: SSO is hard! The goal is the appearance of a coherent
system. If we don't address this in SAML, there won't be
interoperability.
Dave Orchard:
- TCStructure: The use case subgroup started to veer into design, but
then the core subgroup didn't feel that they met in the middle. The
communication among subgroups isn't optimal. Wants to wind down both
subgroups and have the whole TC meet once a week to do the bulk of the
work. Alternatively, a unified "focus team" could work on making design
recommendations up to the biweekly TC meetings.
- ProtocolChoreography: The protocol side focused on a simple
request/response mechanism. Disagrees with Bob Blakley. We need to
define what our protocols are in order to get interoperability. The use
cases and conversations demonstrate this: We're defining workflow (or
choreography or orchestration).
- On sessions, where were those opposed when the use case subgroup was
approving them?
Ken Yagen: pass
Ron Monzillo: pass
Bob Griffin:
- CertsVsPasswords: Identrus faced two issues -- find ways to support
smartcard certs and link the identities with attributes. We shouldn't
simplify the problem to eliminate certs in favor of usernames and
passwords.
- PropagateIDAssertions: We want to be able to propagate identity
assertions, and to propagate privileges into other environments.
Charles Knouse:
- Agrees with DarkNightOfTheSoul. Our spec isn't there yet.
- Hopes the AuthN pass-through issue gets resolved soon.
- ProtocolRecommendations: Wants normative stuff, not
recommendations/guidance.
Hal Lockhart:
- Doesn't think the process is all that broken. Urges us to limit the
scope and size of our work product. Some ideas will have to be deferred.
We have time pressures (not least of which is the analysis that has to
go on to ensure that the result is secure; a more complex spec can delay
this process and make it more expensive).
- PassportHailstorm: We need to consider whether to be compatible with
these systems.
Bill Pope:
- Difficult to discern the scope. Where are the boundaries of the
system?
- Use case diagrams: Some of the actor definitions were not consistent
across the documents.
- Main concerns: SSO and, somewhat, sessions. Longevity of application
context: how do you keep it alive for n days?
Joe Pato:
- We need to clarify the problem. But doesn't agree with Bob Blakley on
SSO and sessions. The assertion part isn't as compelling as connecting
together multiple applications.
Fred Moses:
- The back-office use cases as defined can probably handle HIPAA needs.
Most useful will be the XACML work.
Jeremy Epstein:
- webMethods will be consumers of this stuff, and interoperability is a
prime concern.
- TCB: What parts of the system must be trusted?
- ShouldWeDoSAML: Does the TC think there's still value in doing this?
Marlena Erdos:
- SAML is useful for more than just sessions. Shibboleth federated
administration is an example. The user may be surfing many sites.
Attribute authorities are still useful all on their own. Interoperation
of components that do rich sessions and those that don't could be a
problem.
Evan Prodromou:
- UserSpecificContext: What input does a PDP get? One piece of input is
the subject. (Identity, authorization attributes.) Another is the
object (some resource: what and where. Can be a string). Another is the
action. (Okay to be a string.) The last input is context: everything
else! Two kinds: universal (time of day etc.) and user- specific (IP
address, the application they're using). We don't have user-specific
context as part of our model. This is part of the session state. If we
don't do it, it will be badly done.
Darren Platt:
- Supports TCStructure.
- Issue 5-03:PassThruAuthN: We have a resolution to create a non-goal,
but we need text for it.
- 1-05:FirstContact
- NeedDependsOn: Spec line 487: DependsOn is not motivated by
requirements.
- NeedAudiences: Spec line 455: Audiences is not motivated by
requirements.
- NeedAdvice: Spec line 572: Advice is not motivated by requirements.
- Supports DesignTraceability.
- LimitSubject: Spec line 541: Subject should be scoped by domain and
not contain role or key info.
- PEPNeedsRoleInfo: Spec line 595: Regarding a principal occupying a
certain role: a PEP shouldn't need this.
- KeyDelInClaims: Spec: Claims section supports key delegation. Should
it?
Irving Reid:
- He was reluctant about sessions: good idea, but the text wasn't good.
- Phill's fear (IndexicalReferencesConsideredHarmful) is unfounded, at
least as far as some vendors are concerned. It's not a problem for many
applications and users.
- Even though the design looks PKI- centric, but in practice it probably
isn't going to be a problem.
Michael Lyons:
- Agrees with Joe Pato about sessions. They're a real-world problem that
SAML should solve. It's hard, but we're engineers. Interoperability is
the concern here. At least hooks for sessions should be put into the
spec.
Mark Griesi: pass
Maryann Hondo: pass
Alex Berson: pass
Bill Perry: pass
Marc Chanliau:
- The OASIS board may not pass our spec if it's too complicated. We
don't have another year's worth of window to finish this. We should use
future versions to add to SAML 1.0.
- The scope of the glossary should be redefined. A lot of terms can be
removed. (And "digital signature" should be added.)
Prateek Mishra:
- S2ML took Hits because it had no sessions. But the time constraint
was real. We're facing a big decision: Whether to do a "session spec"
or a foundational thing that doesn't exactly meet end user requirements.
It does meet SSO, putting assertions into payloads, etc., but not cross-
security-domain sessions. Assertions in XML are one layer of the stack,
and sessions feel like a higher layer. We don't want to lose the
momentum of what we set out to do; this shouldn't take too long (past
Q3).
--
Eve Maler +1 781 442 3190
Sun Microsystems XML Technology Development eve.maler @ east.sun.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC