Minutes of 1 day F2F held on 29 September 2010

[Anil Saldhana <Anil.Saldhana@redhat.com>]

  Acknowledgement: Thanks to Steve Coplan for scribing the minutes. :)


Minutes of 29 September 2010 Oasis IDCloud TC Meeting held at Washington DC.

** 1. Roll Call and Agenda Review **

Attendees:

Kurt Roemer Citrix Systems, Inc.
David Turner, Microsoft Corp.
Robert Cope Homeland Security Consultants
Matthew Rutkowski IBM
Gershon Janssen Individual
Thomas Hardjono M.I.T.
Anthony Nadalin Microsoft Corporation
Colin Wallis New Zealand Government
Patrick Harding Ping Identity Corporation
Tomas Gustavsson PrimeKey Solutions AB
Anil Saldhana Red Hat
Doron Cohen SafeNet, Inc.
Darran Rolls SailPoint Technologies
Darren Platt Symplified
Stephen Coplan The 451 Group
John Tolbert The Boeing Company
Brian Marshall Vanguard Integrity Professionals
Siddharth Bajaj VeriSign
Daniel Turissini WidePoint Corporation
Abbie Barbir Individual

Quorum: 12 out of 23 voting members (52%) Achieved.

* Steve Coplan agrees to be the minute taker for a few hours.


**2. Meeting Minutes Approval.**
Deferred.


** 3. Discussion of Definitions/Terminology/Glossary **

Saldhana: Several options exist to integrate definitions into the TC's 
output:
Definitions as a separate document
Hyperlinks within glossary
Noted definitions baked into the TC charter, and TC output is intended 
to serve as a reference document

Should definitions be internally defined, or can the TC leverage 
existing work?
Possibility exists to adopt definitions that overlap with existing OASIS 
definitions – SAML, WS-Trust, ITU-T.
Option to adopt NIST definitions. NIST introduces political 
sensitivities, since it can be perceived as US-centric and focused on 
concerns of US federal agencies. However, since OASIS seen as a neutral 
organization, folding NIST definitions into TC output could reinforce 
the neutrality.

Consensus on iterative approach driven by use case profiles work
definitions emerge from use cases and follow a normalization process
when definitions reach a critical point, they can be consolidated into a 
separate document



** 4. Use Cases Document Template discussion **

Saldhana: should we revisit categorizations, or is the current set and 
format appropriate?
Harding: Create a matrix for use cases based on categorizations, would 
help to determine where use cases span more than a single category and 
identify categories where no use cases exist
Harding: Federation is a “catch all” term for a building block or 
enabling technology for other categories
Roemer: Could we list the technologies that support the use case? Would 
serve the purpose of addressing problem space and provide guidance
Saldhana: Should we expand category definitions to make them less 
technology-specific?
Coplan: There should be consistency in the category characteristics
Rolls: We should look to traditional identity management categories, and 
add account and attribute management:
1.Authentication
2.Authorization
3.Audit
4.Administration
5.Account and Attribute Management

Constructing a matrix around these categories, with additional 
technologies subsumed, would make the deployment models more comprehensible

Rutkowski: Consensus reached on categories, with 'Account Types' 
category held in abeyance until later date.

Harding: Should security tokens be subsumed under authentication, 
authorization or SSO?
Saldanha: Leave a topic as standalone if it falls under multiple categories

Harding: Three-dimensional matrix with initial use case, technology 
components deployment options
Private
Public
Community
Hybrid
and
service models - SaaS, Paas and IaaS

Rolls: Does that imply that we are working on a reference framework on 
top of existing standard discussions – is that an issue of scope?

Saldhana: Not a question of extending or replicating work done in other 
TCs. Intended to supplement standards work by undertaking the process of 
gap analysis of existing standard scopes and generating use case 
profiles to illustrate how standards can be effectively implemented.

Rutkowski: Current use case format seems too rigid. Do we want a 
narrative model with a clear outcome or more of a structured format?

Saldhana: Intention is provide a template that can support a number of 
use cases, but the intention is to generate the framework out of the 
exercise of evaluating several examples, that allows for granularity and 
defines the outcome. First example is Safenet's administrator 
authentication to SaaS app.

Rolls: Could we add an 'actors' section to the use case – that would 
help call out who the use case applies to.

Rutkowski: What is the user story?

Cohen: The user story is that an admin of a SaaS instance is required to 
perform administrative duties. The requirement is that the user is 
authenticated and the necessary identity assurance is performed. The 
technology requirement is that the admin use strong authentication

Coplan: Is strong authentication the appropriate term? How do we avoid 
making a direct product reference. Is it better to phrase it the 
technical requirement as the admin must authenticate with the 
appropriate strength based on a risk model?

Tolbert: Could we expand on this use case to be broader as 'SaaS' 
Privileged Account Access, so that we separate out the workflow to 
create a privileged account within a SaaS instance and the requirements 
for user to authenticate with a set of credentials?

Saldhana: Use cases are not intended to be exhaustive – they should 
represent an angle or an aspect of identity in the cloud. We should have 
a separate use for admin authentication.

Saldhana: Can we discuss a generic user authentication to SaaS use case 
that would serve as a exercise in defining the template?

Coplan: User story is that a user wants to access a third-party 
resource, and the organization's risk management practices require that 
their identity be validated based on an internal identity profile.

Rutkowski: Do we want to use the term resource. Isn't that user story 
too technical and non-specific?

Roemer: We do want some generic description, with some degree of 
technical depth, so the description has broad applicability.

Harding: We should also define dependencies and assumptions about the 
use case – context, environment, business process etc



** 5. Review of Use Cases **
- Boeing Use Cases
- Homeland Security Consultants Use Cases
- Citrix Use Cases
- Primekey Use Cases


Boeing use case :-

Tolbert: TSCP – defense contractors doc sharing conventions – requires 
strong auth, reference to NIST specs,
Tolbert: Integration of documents between collaboration platforms 
establishes need for SSO, authentication, token exchange, level of assurance

Saldhana: Establish a deadline for use case submission – 20 days (oct 20)

Wallis: NZ Govt use case – account linking service – service delivery 
contingent on identity attributes – aggregation


HSC Use Cases :-
Bob Cope: Use case: Distributed HR repositories within an agency, and 
central data collection systems. Need for central point of account 
provisioning, and anchor account used to create local accounts. Issues: 
no coordination of user data, directory synchronization complex and just 
in time provisioning not in place.
Issue of attribute sources – three identity providers accessing a 
resource shared with between three organizations.
Summary: Provisioning. Attribute /Account Management. Synchronization 
and JIT Provisioning.

PrimeKey Use Cases :-
Tomas described his use cases in reasonable detail primarily the Cloud 
Signature Services which require strong authentication.

** 6. Voting on Use Case Template. **
Approved without objection.


** 7. Example Use Case converted into the template **
We chose SafeNet's use cases and Doron Cohen was gracious in helping the 
conversion of his use cases into the normative template.


** 8. Further Discussion of Use Cases **
Citrix Use Cases :-
Kurt Roemer – Logging/Audit Use Case review: how do we generate event 
logs and and audits when users are consuming third-party applications?
Rolls: Is it better to think of this as governance? Audit is the 
business level requirement and logging is the technical requirement. Do 
we want to maintain a standalone category for audit?
Saldhana: Keep as a separate section

Roemer: Do we want to consider non-repudiation as being within the scope 
of audit?
Saldhana: avoided for the moment given legal considerations (based on 
discussion in the room)

Rolls: Logging in the cloud – within scope our outside of scope?
Saldhana: This should be part of our gap analysis – bearing in mind that 
there is a CloudAudit WG on a cloud logging standard.
There was a mention of "cascaded decommissioning", an important problem.


Darren Platt: In order to make this a useful doc, like the idea of 
having a top-down way to organize the use cases. This will help 
organizations identify distinctions between privileged account access vs 
user access in SaaS fairly easy.
Resolution: add an attribute to the use case template which says to 
which of IaaS, Saas etc is this particular use case applicable.


** 9. Adjournment **

Open Questions/Take-aways:-
1) We need a longer f2f when we are ready to normalize the use cases. 
Preferably at a member location with good wifi/internet connectivity.
2) Provisioning/JIT account management is an open question that needs to 
be addressed.