Re: [id-cloud] Architecture for ID-Cloud

[anil.saldhana@redhat.com]

Hi Colin,
I think that should be possible.

From architectural perspective, I feel that the cloud landscape is large and disparate. So rather than prescribe one monolithic generic reference architecture for Cloud IDM, it may be suitable for the TC to stick to the charter and view the end goal to be profiles for collected use cases. 

Now if each of us sends their use cases, I am reasonably confident that we can cover all facets of cloud IDM. To be honest, the last few months have been eye openers for me. Collating the use cases and extracting topics out of them such as Virtualization Security, Auditing, Provisioning/Account Management/Attribute management, Security Token Transformation etc will give us a better shot at actually solving the problems (or recognize the problems).

As part of the profiles, we may have to draw diagrams or generic reference architectures (targeted for that profile) to highlight/elaborate the profile. Thomas's Kerberos submission and Martin's SAP submission have diagrams.

This is what I had in mind when I said profiles may be synonymous with architectures.

As and when we identify gaps, we may inch toward one ore more reference architectures. But these may be side effects of our discussion but not direct artifacts of the TC.

At this time, I request members to accelerate their use case submission so that we have enough discussion material for the coming months. I am sure in few weeks we will have parallel processing of use cases, gaps and profiles.

Regards,
Anil

On Aug 11, 2010, at 8:20 PM, Colin Wallis <Colin.Wallis@dia.govt.nz> wrote:

> 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?
> 
> Cheers
> Colin 
> 
> -----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
> 
>  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
> 
> ---------------------------------------------------------------------
> 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 
> 
> ====
> 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.
> ====
> 
> ---------------------------------------------------------------------
> 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 
>