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

Personally, I'm fine with keeping tightly to scope, and having the documented output call out the shortcomings for an appropriately chartered TC/group as and when, as long as we stand up some kind of 'parking lot' for Architectural (and other delineated issues) as they arise in our discussion/analysis, so we don't have to remember them all (at the end?) at the doc writing stage. 

If we were to take this approach, of course we may need a little bit of discussion from time to time to get consensus that an issue/part of an issue *is* architectural (or whatever) in nature and indeed destined for the parking lot.

That would still be OK scope-wise wouldn't it?


-----Original Message-----
From: Anil Saldhana [mailto:Anil.Saldhana@redhat.com] 
Sent: Wednesday, 11 August 2010 11:18 a.m.
To: id-cloud
Subject: Re: [id-cloud] Architecture for ID-Cloud

   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.


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

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:

CAUTION:  This email message and any attachments contain information that may be confidential and may be LEGALLY PRIVILEGED. If you are not the intended recipient, any use, disclosure or copying of this message or attachments is strictly prohibited. If you have received this email message in error please notify us immediately and erase all copies of the message and attachments. Thank you.

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