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


  Matt,
   thanks for the detailed email and I agree. This TC has a clear entry 
and exit strategy weaved into the charter. We want to limit the work 
exactly to fit with the charter.

We can either get into subjective discussions around architecture or can 
finish the TC work at the earliest and look beyond. :)

The IDCloud TC is not an all encompassing TC for IDM in the cloud that 
tries to solve everything. It is the beginning for future work in the 
space as things get clearer in the industry. All along we gain valuable 
experience working together, discussing the use cases.

In the profiles section of this TC, I am sure we are going to get into 
architectural discussions but they are targeted to the specific 
usecase(s) under target.

Regards,
Anil

On 08/10/2010 05:02 PM, Matt Rutkowski wrote:
> Tom Bishop<tbishop@conformity-inc.com>  wrote on 08/10/2010 03:42:47 PM:
>
>> I assumed the question of architecture was one of timing/priority, not
> whether
>> it was in-scope or out-of-scope.  If mistaken, happy to take
>> guidance.  That said,
>> not trying to stimulate an architecture discussion if the group isn't
>> willing to do so.
>> I assumed the several comments offered during the call yesterday implied
> there
>> are several in the group that are.  Again, happy to take guidance
> ifmistaken.
>> Tom
> It is my belief that going down the path of defining an architecture is an
> activity that clearly goes beyond the intention of this TC's charter of
> in-scope items. Today, many standards bodies devote much time developing
> standard architectures at all descriptive levels (especially security)
> which are then formalized against various modeling techniques using
> different levels of abstraction. Architectures are indeed treated as their
> own standards and we should avoid the compulsion to assume we need to
> define one in order to fulfill our charter's mission.  This is why the
> charter listed several "out-of-scope" items in an attempt to avoid such a
> slippery slope and keep this TC focused on (as closely as possible) the
> use cases themselves in order to identify standards/standards' profiles'
> "gaps".
>
> The value of this TC is in identifying cloud uses cases around Identity
> Mgmt., and describe/suggest how existing standards for ID formats,
> protocols, and profiles can be used to enable these use cases.  Then where
> we find that exiting standards fall short, call out those failures,
> document them and provide that documentation as output (in a timely
> manner) that can be used by other TCs, WGs, or even other SDOs as
> input/feedback where they can work more appropriately to address them.
>
> I suggest we work in earnest against our mandate by submitting and
> compiling Cloud ID use cases, form them into a cohesive structured
> document, then we can discuss and document existing standards (and
> profiles/profile subsets) appropriate to each use case and then lastly
> identify any standards gaps and produce findings.  This set of
> documentation will be the invaluable output of this TC and what IMO was
> intended from the chartering members.
>
> -Matt


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