Anil,
As we discussed in Keystone, the question of "architecture" will necessarily require some
discussion (and agreement) on several basic questions, which I'm certain will be obvious and/or straightforward to some and contentious to others:
1. What's the role of SAML (or at least SAML-like architectures)? Are we assuming a
SAML-based (or SAML-like) architecture, or is SAML allowed/enabled/supported
but not required?
2. Who can authenticate? Do we support a single, trusted authentication source, or will
the architecture allow us to support multiple authentication sources?
3. If "several," are they federated or synchronized in some way?, or does it remain
fragmented?
4. What's the role of OAuth?
5. Do individuals have multiple "identities" with various ways of mapping/resolving between
them, or one identity that can map to multiple roles/responsibilities/contexts?
To my mind, any attempt at an architecture discussion will in fact devolve into discussions about these more basic points. Thoughts?
Tom
On Mon, Aug 9, 2010 at 3:25 PM, Anil Saldhana <> wrote:
Thomas,
as part of the TC work, we have to come up with a document for definitions/glossary. This was something we had discussed at one of the TC meetings and agreed on. So I think this document can formalize the vocabulary. That task has been stalled because Abbie has been away (to start with the ITU-T contributions).
Apart from this, the third stage of the TC involves profiles for the various use cases. This certainly is synonymous with architecture for those use cases?
I feel coming up with a generic architecture for the entire TC charter (IDM in the cloud) will probably be contentious and lacking completion. Would it be better to look at architectures for various use cases that we identify?
If we are looking at simple architecture to highlight the scope of the TC, may be the glossary document may include such diagrams?
Open to feedback.
Regards,
Anil
On 08/09/2010 02:36 PM, Thomas Hardjono wrote:
soaphub
Colin Wallis1: Brian..alternatives to Directory synchronisation
sounds like an architectural approach discussion to me,,
I'd like to voice agreement with Colin and perhaps start
a thread on the need for an ID-cloud architecture.
I know we need to complete the use-cases document first,
but I think we're getting the picture that many of the
use-cases share common problem-points.
And a common general architecture is now needed.
Perhaps we could start by a simple architecture in which
three entities exist:
(a) Identity Provider,
(b) Service Provider and
(c) Enterprise,
and all share the same basic capabilities:
(i) authentication endpoint,
(ii) SAML endpoint,
(iii) Provisioning end-point,
(iv) Identity-directory synchronization end-point.
(PS. Some people may see the end-points as APIs).
/thomas/
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
