[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes of IDCloud TC Meeting - 01 Nov 2010
----------------------------------------
MINUTES
OASIS IDCloud TC Meeting
01 November 2010, 02:00pm ET, 19:00 CET
----------------------------------------
NEW ACTION ITEMS:
ALL - Update use cases in new template format.
----------------------------------------
Scribe: Gershon Janssen
----------------------------------------
1. Roll Call, Agenda Review and Minute Taker Nomination
Meeting Attendees
Dale Moberg Axway Software
Jeffrey Broberg CA Technologies
Morteza Ansari Cisco Systems, Inc.
Kurt Roemer Citrix Systems, Inc.
Tom Bishop Conformity
Mark Robinton HID Global
Robert Cope Homeland Security Consultants
Matthew Rutkowski IBM
Gershon Janssen Individual
Michael Stiefel* Individual
Benny Koren Mellanox Technologies
Dale Olds Novell
Patrick Harding Ping Identity Corporation*
Anil Saldhana Red Hat
Darran Rolls SailPoint Technologies
Travis Yoes Symplified
Stephen Coplan The 451 Group
John Tolbert The Boeing Company
Kyle Austin TriCipher, Inc.
Jerry Smith US Department of Defense (DoD)
Brian Marshall Vanguard Integrity Professionals
Siddharth Bajaj VeriSign
Daniel Turissini WidePoint Corporation
This meeting quorates. (12 out of 20 voting members: 60%)
Status: Colin Walis (NZ Govt) loses voting rights.
No changes and / or additions to the agenda.
----------------------------------------
2. Approval of October 18th Meeting Minutes
- 18 October 2010:
http://lists.oasis-open.org/archives/id-cloud/201011/msg00000.html
Jerry Smith moves to approve the minutes; Patrick Harding seconds. Minutes approved unanimously.
----------------------------------------
3. Elevation of Gershon Janssen to role of Secretary
Patrick Harding move; Jerry Smith seconds. Unanimous consent.
----------------------------------------
4. Review of PrimeKey, Red Hat and SafeNet updated Use Cases in template format.
-http://www.oasis-open.org/committees/document.php?document_id=39864
(PrimeKey Solutions AB)
-http://lists.oasis-open.org/archives/id-cloud/201010/msg00018.html (Red Hat)
-http://lists.oasis-open.org/archives/id-cloud/201010/msg00019.html (SafeNet)
Anil Saldhana: Request to update use cases in new template format.
----------------------------------------
5. Continuation of discussion of IDM categories.
http://wiki.oasis-open.org/id-cloud/UseCaseCategories
- Authentication
Typically most Identity Systems define a level of authentication from an eco-system point of view. Not sure what we should do with this item.
Proposed objective for this TC is to (1) perform use case collection (2) find gaps in existing standards.
When discussing / brainstorming on this topic and start looking at what other groups are doing or already have done, we can then identify the gaps.
Identified sub items for authentication:
(1) What types of authentication are required
(2) Levels of assurance with authentication
(3) What token formats
(4) Multi-factor authentication
(5) Single sign on
(6) External authentication services
Cloud based services may be utilizing external authentication services
Patrick Harding: Something similar to this is already within the NIST area, especially as a part of their Assurance Framework. We should leverage that information and no try to reinvent it. To identify topics, we can use the NIST framework documents.
Anil Saldhana: We shouldn’t go into too much detail / differentiate on items, as long as we can direct to a location where it is described.
Patrick Harding: Question marks are on external authentication; isn’t this orthogonal to the list of things. An enterprise can be the IDP and be responsible for authentication and have multi-factor auth and levels of assurance, still authentication services may be leveraged on-demand from Google, Yahoo or Microsoft – this is seen as an orthogonal thing.
Maybe we should differentiate the notion of on premise authentication from on-demand authentication.
External as mentioned seems to be most close to on demand authentication.
Anil Saldhana: What challenges exists with external providers and a provider that one hosts itself, e.g. one hosts a private cloud and subscribes to a service that is owned by another group / department within the same company. Is it needed to qualify on-demand further?
Depends on how you think about it. Might describe it as an IDP service: enterprise IDP service, on-demand IDP service. How can a relying party rely on an IDP.
Any input from the federal side?
Bob Cope: There are no standards for the MiniCRLs for low bandwith distribution of the replication data. There is OCSV, SVVP, LDAP for CRLs. This is important to DSC, DOD and other places that are worried about being disconnected from the IDP and still being able to authenticate on your own.
Anil Saldhana: Is this local authentication which requires e.g. directory sync depending on token type.
Anil Saldhana: Request to Bob to reply to mail thread on authentication to put this information in.
- Security token formats
Multiple formats to look at: SAML, etc.. We need to identify all token formats.
Patrick Harding: Should we capture all the possibilities?
Anil Saldhana: Yes, list all used (private and public) as one of the TC deliverables. We can bring them together, collect and normalize them.
Some of the use cases need some additional work in this area. It is recognized that conversion to the new template is time consuming though.
What token formats should we be looking at? E.g. SAML tokens?
Matthew Ruskowski: We need to understand the behavior and the data the tokens carry (heavy weight / light weight). Distinguish the application in use of the token rather than list all formats.
List token formats, will this be a long list?
Suggested is to categorize by reference or by value.
OAuth is extending the conversation as is JSON Web Token what that actually needs. Consider SAML for example: we condense lots of token formats, lots of profiles and bindings. Not all token formats are being using in a practical sense.
Anil Saldhana: Should we be looking at how applications use the token formats or should we list the major ones?
Patrick Harding: Distinguish between the well know token formats as a part of this, which will likely get end up discussed in the context of certain standards and how standard work together. We are doing some work around single sign on for APIs in the cloud where we use the combination of exchanging SAML tokens for e.g. JSON Web Tokens.
What format can we use to tackle this token format topic.
Suggestion: take a look at WS-Security token profiles – 6 are standardized which is a reasonable set of tokens, which can be documented within this document and maybe add placeholders for tokens that are materializing in the OAuth work now.
TC thinks this is a good approach so we can get a list of the prominent tokens and have placeholders for future work for OAuth and other working groups.
Matthew Ruskowski: We shouldn’t try to create additional categories. We need to have use cases that drive the need for interactions and types of data and things we did not thought of.
Anil Saldhana: Approach suggested: not exhaustive search but at least from a use case perspective that we have obtained up till now to start listing the major ones. As we get more use cases we start filling in the sections in the draft document to identify new token formats.
Suggestion to add “Level of assurance” to the trust section in de draft document? No objections.
- Trust Brokers
Anil Saldhana: Topic Trust Brokers? What role do they play? Do they play a role in on-demand authentication?
Trust brokers are going to be an important area for some of the cloud based security companies. Trust brokers are going to be important in the next 1-2 years. (Patrick and Dan had some exposure to trust brokers)
How does trust brokering affect the area of authentication with inside the discussion of on premises and on-demand authentication; how does trust brokering play a role in authentication?
Tom Bishop: With on premises trust is always transitive in the sense that I can accept trust and pass it on and in the act of doing so I can increase or decrease the level of trust that one should have in the token.
Kurt Roemer: Have a look at the trust relationships and how they are establish between everything, but even more than that, take a look at some of the assumptions that trust was based on. Because it really gets in to a risk case decision especially if you are looking at any integration with ID systems, you really have to understand those assumptions, because you won’t be trusting different entities equally.
Tom Bishop: That is where lessons learned in life in the DNS systems, where you have authoritated and unauthoritated binding services, the systems doesn’t work without some sense of authority.
Matthew Ruskowski: Use cases can nominate their own category that they see fit, but essentially a matrix is setup in the document that tries to tell people which area of the category that use case sits upon. So that many use cases can cover one area.
----------------------------------------
6. Other Business
- Jerry Smith, announcement: NIST is having a second Cloud Computing workshop end of this week. Jerry Smith is on a panel and has created some slides, which also highlight this TCs work.
- Next meeting will be held on 15 November 2010, 02.00pm ET, 20.00 CET
- Topics for next meeting:
- (just-in-time) provisioning
- API access
- Start developing use cases as a group in certain areas; we hear use cases on the phone here during the TC meeting; maybe we should start developing those as a group.
- Matthew Ruskowski heard interesting topics: token transformation, concepts on OAuth, concepts on crossing trust boundaries from which use cases can be developed. Suggestion to work on use cases from meeting minutes on discussed topics.
----------------------------------------
7. Adjourn
Meeting adjourned.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]