OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

id-cloud message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [id-cloud] Architecture for ID-Cloud

Throwing more fuel on the fire...

Profiles are not synonymous with architecture as I understand them.

Use cases outline how a service/application/subsystem behaves given some
external action. This includes both normal and error cases. This corresponds
to the approach we have started. A profile might include what technologies
could be used to implement the use cases.

Even a reference architecture is a fairly complicated beast because you have
to think about implementation details and prescriptive guidance. Is that a
path we want to go down? I personally am interested in ID-cloud
architecture, and Thomas' questions are a good starting point, but that
seems out of scope for the TC.

Michael Stiefel

-----Original Message-----
From: Anil Saldhana [mailto:Anil.Saldhana@redhat.com] 
Sent: Monday, August 09, 2010 4:26 PM
To: id-cloud@lists.oasis-open.org
Subject: Re: [id-cloud] Architecture for ID-Cloud

   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.


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:

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]