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

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

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


Subject: Re: meeting at F2F


Ajay:

This is fantastic. If you can extend your stay until Wednesday, that is 
even better and come to the BBQ at my house.

As far as the presentation, I'll defer that to the TC. We can discuss 
Tuesday AM.

C U In Van!!

Duane

Ajay Madhok wrote:

> * Hi Duane,*
>
> * *
>
> *I am planning to get to Vancouver on the 19^th evening and get to 
> know the TC a little bit.*
>
> * *
>
> *If your time and schedule permits, I can take the opportunity to 
> present a few slides (< 10) on the role of Identity in SOA on the 
> 20^th morning. I will leave by 20^th afternoon.*
>
> * *
>
> *Attached is a quick and dirty draft (key points) for the storyline – 
> see if it makes sense to you?*
>
> * *
>
> *Cheers,*
>
> * *
>
> *=Ajay*
>
> * *
>
> *The Role of Identity in SOA*
>
> Co-ordination
>
> SOA is an approach to distributed computing that uses an abstraction 
> layer to expose application functionality as business-oriented 
> services. These services are typically location-independent and 
> discoverable on the network. This means the services, their component 
> resources, their providers, and their consumers all need to be 
> identified in a manner that is independent of location, domain, 
> application, etc.
>
> In particular, SOA requires secure identification of the TO and FROM 
> endpoints (where the message originated, and to whom the message is 
> being delivered). To avoid brittleness and to maximize composability 
> and reusability, these endpoints should be identified abstractly, 
> uniquely, persistently and globally. While Web Services are necessary 
> for a SOA, without an identity architecture they are insufficient.
>
> Transaction Capability
>
> At an abstract level, any transaction is ultimately between two 
> identities identified within one or more domains of authority. Unless 
> these identities and their domains of authority can be strongly 
> associated with accountable real-world actors, there is no way to 
> maintain trust in the network. Theoretically, this can be simple as 
> implementing a directory within a domain, or a meta-directory for 
> multiple domains. However this approach does not work at Internet 
> scale. Large scale deployment requires federated identity 
> infrastructures that enable an infinite number of peer-to-peer 
> relationships and “circles of trust”.
>
> Identity Context
>
> Identifiers are typically established on a per application basis and 
> do not work across multiple contexts. SOA can actually make this 
> problem worse: if a service composition layer acts as a layer of 
> abstraction (masking the details of the underlying technology 
> implementation from the service consumers), and if each service 
> abstracts the context of its own resources from the underlying 
> applications (for example user identity), then it can be very 
> difficult to associate the users of the overall composite 
> functionality because the SOA itself provides no overall context (be 
> it security or semantics).
>
> Control Layer
>
> Control must be implemented in SOA to mediate data and services 
> sharing. SOA often seems to be concerned primilarly with Access 
> Control, however control is more than just, “Who can get this data or 
> access this service?” There are four additional layers of the control 
> hierarchy that are equally important but much harder to implement 
> logically:
>
> · Privacy and Usage Control – for what purposes will shared data be 
> used? For what will it NOT be used? How will it be redistributed, or 
> NOT redistributed?
>
> · Synchronization Control – how will multiple copies and versions of 
> the data kept synchronized once it crosses domain boundaries?
>
> · Expiry or Recall Control – what is the ability to recall or 
> invalidate data that was shared earlier?
>
> · Compliance and Accountability Control – how can compliance with 
> these policies be monitored and accountability be enforced?
>
> Today, only access control is implemented on the wire. The other 
> controls are implemented offline using physical constructs such as 
> legal contracts or agreements (e.g., privacy policies, data escrows, 
> NDAs). Arriving an a machine-readable framework for these controls 
> would make them much easier and faster to implement for all parties.
>
> Shared Semantics
>
> One of the pervasive problems in SOA is similar to the key problem in 
> systems integration—the cross-context mapping of resources and data so 
> that they can be shared and consumed/understood beyond the province of 
> the local domain. This, too, is a problem of identity—establishing a 
> shared identity of subjects, topics, and concepts in taxonomies and 
> ontologies.
>
> In some applications the scope of shared semantics is narrow enough 
> that it can be “hardwired” or established out-of-band. However many 
> new net-centric applications are finding the need to be able to 
> establish and maintain shared semantics as a dynamic function of the 
> application or application environment. This trend is expected to 
> increase with the adoption of SOA as the online environment becomes 
> progressively richer and capable of dynamic discovery and integration.
>
> Therefore integrating identity as part of the SOA baseline has the 
> additional advantage of providing a uniform platform for shared 
> semantics that can be leveraged across all services, service 
> providers, and service consumers.
>
> * *
>


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