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

   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/

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