[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [security-services] SAMLng (nee SAML v2.0) brainstroming items/features
Below's the message from Kobielus that I said I'd find and forward again, along
with the minutes from the 30-Apr-2002 where we discussed/brainstormed possible
SAMLng items/features.
JeffH
-------- Original Message --------
Date: Tue, 30 Apr 2002 09:43:47 -0700
From: Jeff Hodges <Jeff.Hodges@sun.com>
Subject: [security-services] [Fwd: Some Potential Future SAML Features for Your
Consideration]
To: oasis sstc <security-services@lists.oasis-open.org>
Here's the raw list I mentioned on the call today. We should step through this
list and categorize the items into categories such as..
* new profile of SAML
* new use-case of SAML
* new SAML feature
(other categories?)
of course all the items we brainstormed on the call should also be so
categorized.
thanks,
JeffH
Date: Wed, 3 Apr 2002 13:44:07 -0700
From: James Kobielus <jkobielus@burtongroup.com>
Subject: Some Potential Future SAML Features for Your Consideration
To: "'Jeff.Hodges@sun.com'" <Jeff.Hodges@Sun.COM>
Jeff:
As promised, here's the preliminary list of potential future SAML features,
as identified through discussions with various members of the OASIS SSTC:
* SOAP SAML profile
* Encryption of SAML assertions via XML Encryption
* SAML explicit reference to XACML policy-definition language
* SAML implementation guidelines and implementation profiles/subsets
* SAML use-case and profiles for authorization service
* SAML use-case and profiles for application-to-application, B2B, and
back-office transactions
* SAML use-case for multilevel access controls
* SAML use-case for multi-participant transactional workflows
* SAML credentials collector and credentials assertions
* SAML session authority, session assertions, and dynamic
session-management (login/logout) mechanisms that operate across domains
* Definition of core/baseline assertion attributes (e.g., roles) that
can be understood, by default, among federated SAML domains
* Hierarchical delegation of privileges among federated attribute
authorities
* Mechanisms for SAML-enabled servers to define mutual trust
relationships and authenticate each other
* Mechanisms for caching or storing SAML assertions persistently at
two or more federated sites
* Standard language for expressing role-based access controls enforced
by infrastructure servers
* Standard language for expressing security processing workflow
definitions enforced by trusted servers
* Assurance levels for authentication contexts associated with various
SAML authentication assertions
* Privacy and anonymity features such as defined under Shibboleth
(e.g., attribute release policies, attribute acceptance policies, "where are
you from?"/handler service)
* Support for Passport and Liberty Alliance authentication and subject
confirmation methods in SAML
* SAML site/service/profile/binding discovery through integration with
UDDI, WSDL, and DNS/SRV RR
* SAML integration of ebXML Message Service Specification (MSS)
extensions to SOAP 1.1 for reliable, guaranteed messaging
* SAML support for wireless browser profiles over WAP/WSP/WTP/WTLS
Jim
James Kobielus
Senior Analyst
-----------------------------------------------------------------
Subject: [security-services] Minutes for Telecon, Tuesday 30 April 2002
http://lists.oasis-open.org/archives/security-services/200204/msg00131.html
Minutes for SSTC Telecon, Tuesday 30 April 2002
Dial in info: +1 334 262 0740 #856956
Minutes taken by Steve Anderson
>
>
> 1. Roll call
>
- Attendance attached to bottom of these minutes
- Quorum achieved
>
> 2. What Next after v1.0?
>
- Joe: brainstorm what do we need to do next
- examples:
- SOAP Profile
- Kerberos & SAML
- WS-Security & SAML
- Don: his customers interested in mid-tier, as opposed to perimeter
that SAML seems to focus on now
- this is area where EJB, CORBA, C++ exists
- Hal: talking about a profile, since assertions are useable
everywhere?
- Don: yes
- Hal: are you suggesting that a new use case is necessary?
- Don: would have to look at it more, but could be
- RLBob: this is of interest to people in the Shib area also,
along with other, more complex use cases
- Hal: 2 items set aside last year
- pass-through authN
- dynamic sessions
- Jeff: session management, in general, including static
sessions as well as dynamic
- RLBob: some standard way for bringing in X.500 attributes
- Phill: WS-Security
- changing WS-Security so that there is a profile there that
says where to put SAML assertions in the WS-Security payload
- how to use WS-Security for a SAML transport
- Hal: answering these questions should be a pre-req for issuing
our own SOAP profile
- Hal: XACML was planning to propose extensions to SAML
- Carlisle: example of 'obligations' or actions that PDP needs
to express to a PEP along with a decision
- Phill: are these conditions?
- Carlisle: not clear that this fits well into conditions
- Phill: so this is not a basis for trusting or acting on the
assertion
- Jeff: Joe, James Kobielus sent msg to us, which we should send
out now
- list of "it'd be great if SAML did this ..." collected from
Burton's discussion with other companies
- [sent to list during call]
- Don: would like to consider delegation
- Jeff: in what sense?
- Don: a call goes through multiple intermediates, which speak
for the initial client
- Hal: need use cases, because "delegation" can mean different
things
- Joe: perfectly reasonable to add use cases now
- Rob: Liberty Alliance
- some members have heard rumors that Project Liberty has
something to do with SAML and speculate that there may be
some useful cross-pollination to be had
- co-chairs concur, but note that the SSTC needs to wait for
Liberty folk to come forward to the SSTC
- as Project Liberty does not yet have a formal model for
liaison with the SSTC, we can only wait for Project
Liberty to approach the SSTC with any relevant information
before being able to further consider anything in that context
- SSTC members who participate in Project Liberty are encouraged
to make sure that necessary communication occurs and to inform
Project Liberty that SSTC is receptive to establishing a
formal liaison process.
- Hal: looking through deferred items from last issues list
- SASL
- foggy recollection of what this was originally about
- RLBob: use of SAML assertions in existing authN protocols
- Hal: SASL defines authN methods, and we've deliberately
NOT done that
- RLBob: browser profiles accepts SAML assertion in place
of HTTP Basic, Digest, etc, so in a sense, this is an
authN mechanism
- use of intermediaries, adding or removing assertions, etc
- some of the thinking there was that XML Protocol was going
to support/provide this, so SAML should support it too
- Joe: was this raised by Bob Blakely?
- Hal: thought it was Dave Orchard
- runtime privacy
- RLBob: Shib has made this a centerpiece
- Hal: heard a rumor that Liberty was working on this
- encryption - we vowed to incorporate this
- Jeff: very important
- XML Enc nearing standardization
- Hal: would we not do this similar to what we've done with
XMLSig?
- Jeff: still needs use cases
- Phill: could have encrypted statements or encrypted advice
- encrypted conditions would be interesting
- there was question around anonymity technique
- how to create an anonymous name identifier
- not sure if anyone wants to bring this back up
- privacy considerations
- people/orgs can control which attrs are given out and
under what circumstances
- we originally treated it as something that can be done,
but doesn't need standard around it
- feature to express that an assertion should not be cached
- dependency audit?
- Prateek: thinks it was infamous "validity depends on"
issue
- nested attrs
- one of many definitions of roles
- you're a member of a group by virtue of belonging to
another group that is a member of the original group in
question
- Don: couldn't this be done by XACML
- Hal: could be
- negative assertions
- discovery of authN protocols, presumably what is available
from an authN authority
- people should look through last issues list
- Jeff: do we want to run through Jim K's list?
- Hal: looks like Jim's list include much of what we've talked
about
- Jeff: need to consolidate and send out to list
- Hal: important to identify 5 or so top priorities
- Joe: intention here was to get ideas out on table, and get
people thinking
- Joe: other topics for discussion today?
- Hal: update on Catalyst
- Prateek: exact format of administrative model, etc, has been
posted to SAML-Dev mail list
- rehearsals (East & West coast versions) have been scheduled
for 17 June
- about 12 companies involved
- certain amount of concern/interest in things other than
browser artifact
- Carlisle: do you have all contact names you need?
- Prateek: no, specifically missing Entrust
- Carlisle: will send name
- Hal: hint to web site admin, there's no link to SAML-Dev
mailing list from SSTC site
- Jeff: will fix
- Hal: if orgs want to participate, contact us quickly!!
- Rob: if enough people will be at Catalyst, would it be useful
to hold 1-day FTF afterward?
- sounds like a good thing
- Eve: starting to collect editorial changes
- Joe: there is new template for OASIS spec
- Eve made it!
- not worth migrating to this template yet
- confusion over OASIS standardization timeframe
- submission is definitely 1 June
- unclear whether it is a 30/60/90 day process for ratification
- Joe: looking forward to SAML Dev group to find issues
- Hal: expects issues to be more cases of ambiguity needing
clarification, rather than true semantic issues
- Eve: SAML Dev group has opportunity to accumulate all out of
band coordination issues necessary for interoperability
- Rob: (regarding OASIS ratification timeline) reading from DSML
call for vote, OASIS members have 1 calendar quarter to
review, and 30 days to vote
- Eve: getting back to editorial changes, next week will be a
problem due to travel obligations, but week after is possible
- Concern over getting company names accurate
- we just have one month before submitting to Karl
- Joe: next meeting
- doesn't think we need meeting next week
- Prateek: SAML Interop wanted to take up the off week
- Jeff: we used to use off week for focus group calls, which
would good time for SAML Interop
- that will be on different phone number
- Eve: so she will cancel this number for 7 May & 21 May
- phone number will be posted shortly for those calls
- Joe: after 1 June submission, we can reconsider frequency of
formal calls
- next formal SAML call will be 14 May
>
> 3. Adjourn
>
- Adjourned
---
end
--- Begin Message ---
- From: James Kobielus <jkobielus@burtongroup.com>
- To: "'Jeff.Hodges@sun.com'" <Jeff.Hodges@Sun.COM>
- Date: Wed, 3 Apr 2002 13:44:07 -0700
Jeff: As promised, here's the preliminary list of potential future SAML features, as identified through discussions with various members of the OASIS SSTC: * SOAP SAML profile * Encryption of SAML assertions via XML Encryption * SAML explicit reference to XACML policy-definition language * SAML implementation guidelines and implementation profiles/subsets * SAML use-case and profiles for authorization service * SAML use-case and profiles for application-to-application, B2B, and back-office transactions * SAML use-case for multilevel access controls * SAML use-case for multi-participant transactional workflows * SAML credentials collector and credentials assertions * SAML session authority, session assertions, and dynamic session-management (login/logout) mechanisms that operate across domains * Definition of core/baseline assertion attributes (e.g., roles) that can be understood, by default, among federated SAML domains * Hierarchical delegation of privileges among federated attribute authorities * Mechanisms for SAML-enabled servers to define mutual trust relationships and authenticate each other * Mechanisms for caching or storing SAML assertions persistently at two or more federated sites * Standard language for expressing role-based access controls enforced by infrastructure servers * Standard language for expressing security processing workflow definitions enforced by trusted servers * Assurance levels for authentication contexts associated with various SAML authentication assertions * Privacy and anonymity features such as defined under Shibboleth (e.g., attribute release policies, attribute acceptance policies, "where are you from?"/handler service) * Support for Passport and Liberty Alliance authentication and subject confirmation methods in SAML * SAML site/service/profile/binding discovery through integration with UDDI, WSDL, and DNS/SRV RR * SAML integration of ebXML Message Service Specification (MSS) extensions to SOAP 1.1 for reliable, guaranteed messaging * SAML support for wireless browser profiles over WAP/WSP/WTP/WTLS Jim James Kobielus Senior Analyst Burton Group 6006 John Roccato Court Alexandria VA 22310 703-924-6224 (phone and fax) USA Eastern timezone (GMT-5; Washington DC area) www.burtongroup.com "Driving Network Evolution" Hope we see you at Burton Group's Catalyst 2002! "Breakthroughs come from pressure and patience applied persistently over time and obstacles."--jgk "Success is just one long street fight."--Milton Berle--- End Message ---
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC