Thoughts on Token Technology Trends- No: 41

This is a link to the presentation I gave to the Trust Elevation WG at OASIS, headed by Dr. Abbie Barbir.  I might extend the time frame to post the reminder 59 thoughts around token trends (not within the 100 days) to late 2012.

Thoughts on Token Technology Trends- No: 40

And also Microsoft supports a type of Access Tokens in its operating system.

Thoughts on Token Technology Trends- No: 39

In the Data Tokenization space -- we need to go beyond simple data element tokenization (such as SS# and PAN) and leverage a Data Tokenization Platform such as the Intel Token Broker. The idea is to have a tokenized representation of all "data" resource - which includes a table, a db or directory. See the demo and read the papers. Such Data STS are also integrated into XACML based entitlement systems (such as Axiomatics and Oracle EM).

Thoughts on Token Technology Trends- No: 38

Of course when you have major mainframe applications and mainframe batch jobs still in production, we need to extend the legacy RACF authentication of such legacy systems and specialized implementation such as eZtoken enables these tokenized representation.

Thoughts on Token Technology Trends- No: 37

While OATH tokens are Authentication tokens we also have OAUTH tokens as access tokens. Amongst Access tokens we can have tokens such as an RBACtoken or a XrML token that offers tokenized representation of access privileges for a user. Very useful when access decisions are taken for multiple distributed resources and in collaboration with multiple access tokens.

Thoughts on Token Technology Trends- No: 36

Another popular SAML token is the Web Service Security SAML token, which provides the capability to federate a Tokenized representation of a Web Service and the messages it contains. Majority of the STS (secure token services) support this profile, and it is very useful for XACML (policies) to inter-operate with WS-Policy as well. The WSS-SAML token acts as the identifier to align both policy space.

Thoughts on Token Technology Trends- No: 35

Similar to the approach taken by the SPENGO effort in the past (negotiated authentication), OATH is another initiative that aligns a few Authentication methods and tokens, such as; Standalone OTP generators, Smart Cards, USB Key FOBs, Software tokens and Trusted Platform Module (TPM) tokens via client negotiated framework with STS (secure token services). The power of OATH token is that it is a framework that is token agnostic and authN mechanism agnostic, and that it will have commercial implementations via Ping STS and others. Therefore if you see a OATH token in a STS representing a subject - you can expect that it is negotiated with the client application or application type before it is generated.

Thoughts on Token Technology Trends- No: 34

Integrating Tokens into a Map is one of the key functions of a STS (secure token service). STS can initiate tokens, translate tokens, transfer tokens, map tokens and more. Similar to how in the past we had a Kerberos Token aligned with a PKI token, we also have extensions of Kerberos token to the browser world (SSO token) via the SAML Kerberos WebSSO token. This is a very useful approach to authenticate applications (client applications and server applications) and can augment user level authentication and device authentication (such as OTP token and TPM token).

Thoughts on Token Technology Trends- No: 33

Before we can delve into the various SAML token types (which are also referenced as SAML profiles) - its is also important to note that there are additional SSO tokens, such as OBtoken (Oblix tokens in Oracle Access Manager), SMtokens (Siteminder tokens), CDSSO tokens (Sun Java Systems Access Manager -now Oracle), TivoliAM token (IBM AM), WinSSO token (MS) and more. The past decade we have seen several thousand deployments of these software that are all part of the access manager space (not federation manager space that adds a SAML context for federation setup - primary function of an STS). Other than the OPenSSO project (which was a Sun Open Source project -that combined - Access Management, STS/Federation, Entitlement Management, etc., which is under Oracle now, I am not aware of any system that combines these areas together, unfortunately. They are treated as separate products.

Thoughts on Token Technology Trends- No: 32

SWIFT for Secure Widespread Identifiers for Federated Telecom, has also created the notion of a SWIFT Token with an emphasis on Aligning Attribute Authorities around a SWIFT token. Since telecom operators own the Access Networks and can bootstrap a mobile devise into the Access Network as part of an Admission process, SWIFT tokens as virtual identifiers to align attribute authority can come in very useful.

Thoughts on Token Technology Trends- No: 31

One of the Key Tokens that is leveraged by a Application and/or Browsers to NEGOTIATE an Authentication Mechanism with the back-end server is SPENGO token. A SPENGO Token, that can carry for example a Kerberos Token. Typical usage is an environment that needs negotiated authentication -when there is multiple authentication systems, SPENGO is used and is supported by majority of the Browser's including Google Chrome.

Thoughts on Token Technology Trends- No: 30

One key differentiation between time based and event based OTP/Tokens (RSA Secure ID like systems are time based) - is that event based OTP tokens are also critical post-authentication - in session or in-transaction subject validation.  These types of event token -- are extremely useful for context driven target rule sets, as a 2nd factor - contextual 2nd factor or 3rd factor. Note: Time, Event, USB, RFID, NFC and other related periphery tokens all-have influence over a device posture token and are all run time representation of a context (a set of attributes generated by a system post successful execution of a certain set of controls - in layer 1 to 7 of the OSI stack).

Thoughts on Token Technology Trends- No: 29

One of the more commonly known and widespread usage of the term "tokens" is for the RSA secureid token. A device that generates a one time password - a "transient token" based on what you have and what you know "a PIN" - and can be augmented with axcionics like systems that add bio-metrics if needed. This is the type of token that increases the posture of a "subject: user + device"

Thoughts on Token Technology Trends- No: 28

Another influencer of the posture token (in terms of periphery token) is the RFID tokens or tags (in conjunction with USN tokens and NFC tokens).

Thoughts on Token Technology Trends- No: 27

Another such periphery token that can increase or decrease the integrity representing posture token is a USB token. Non-provisioned adhoc USB tokens generated will basically reduce the posture tokens attribute value representations. However since these USB tokens themselves can be used as (a pre provisioned initiating vector) secure storage of certificate/PKI, SIM, and other soft tokens - they can be added to the client device overall to increase the posture tokens attribute values.

Thoughts on Token Technology Trends- No: 26

Related to Posture Tokens that act as a runtime representation of validated and verified integrity attributes about a device and its connection, the contiguity and continuity of the integrity posture is not a given. Depending on the context and use case (application) the device is running the posture token will be re-aligned. Influencers of such posture tokens about lets say a mobile device are additional periphery contexts also represented by tokens. One such token is an NFC token.

Thoughts on Token Technology Trends- No: 25

In conjunction with external entity posture (such as client devices) the perimeter PDP can also produce a Network Threat Level Posture token - based on current Threats that are active. Trendmicro like systems generate such threat level tokens - it can range from the access networks a perimeter network connects to (such as a mobile network), the enterprise network and the SP network (cloud SP). These types of tokens adds another layer of Intelligence to measuring an Integrity Level of an end to end Client to Service Connection.

Thoughts on Token Technology Trends- No: 24

Ultimately leveraging the path and packet tokenization and protocol and port tokenization - a comprehensive Perimeter PDP should generate Posture Tokens - that captures in Real Time the Integrity level of a device and its connection (client device and server device e2e). This in general should be generated post execution of all the control functions that are performed by; UTM -including Intrusion Detection and Prevention control functions, IP FW functions, VPN control functions, admission control functions, and more. The POSTURE TOKENS generated at Runtime is from a comprehensive combination perimeter PDP.

Thoughts on Token Technology Trends- No: 23

Packet and Protocol Port (tokenized ports -NAT and PAT)  firewalls (a farm of firewalls) generate path and packet tokens after protocol and port level rules are full enforced. This relates to Appliances such as Cisco ASA that sit on the Perimeter (DMZ) and functions a Packet FW, DPI, NAC, IDS/IPS and UTM all in one - concerted and co-ordinated to generate Posture Tokens -around the integrity of the device and the connection.

Thoughts on Token Technology Trends- No: 22

Token ring was a protocol that leveraged packet tokenization, and with MPLS token buckets are heavily utilized as well. The insertion of tokens within IPv6 packets allows for a rich set of capabilities around identification, authN and authZ of packets as well. Packet tokens augment Path tokens and are combined with protocol tokens to determine (policy based) posture tokens.

Thoughts on Token Technology Trends- No: 21

The next 10 entries will revoke around the topics of DMZ perimeter PDP and network tokens, such as Path Tokens, Packet Tokens, Protocol Token, Posture tokens and the likes that in essence helps validate the integrity of a network connection, network session, device connection (both client and server devices) and more. See a well written paper here.

Thoughts on Token Technology Trends- No: 20

Along the lines of decoupling an Authentication Token from a STS SAML token, which is a key concept to digest, the idea behind adaptive authentication (such as OAAM) also is critical - since the set of subject tokens made necessary is dependent on the composite risk token associated with the resource consumed and the composite risk token associated with the subject as well. SO thus far we have covered Risk tokens, AuthN tokens, SAMLtokens, etc., in the 1st 20 entries. Now the focus will move on to a related area which is Network tokens and Integrity tokens and more.

Thoughts on Token Technology Trends- No: 19

In some cases innovative companies such as Axcionics generate all three token types (what you have, what you are and what you know) - SIM+OTP+BioMetric all in one to initiate a SAML Session. OpenSSO as an STS was integrated with Axionics as an Authentication mechanism as well. Hence a combination of tokens were generated at the get go and associated with a SAMLtoken in STS.

Thoughts on Token Technology Trends- No: 18

If one can start with a hard token that represents an initiating vector and leverage some sort of biometric credentials (non intrusive) to authenticate a user, and bind the two tokens (or map the tokens with a SAMLtoken) using STS - one of the common ways to integrate and align to authenticated resources within an enterprise that has applications (application with a authN token) is via kerberos (common and popular). This is a key reason why we have SAMLkerberos profile and approaches to integration leveraging an STS.

Thoughts on Token Technology Trends- No: 17

Any hard token acting as the "initiating vector" allows for the STS to bind other token types to it. In general - when authenticating an entity - in this case a subject - similar to a hard token associated with a device (tamper resistant), a hard token associated with a human being is obviously Bio Metrics. The extensibility of the Biomentric AuthN tokens are also critical - such as DNA, fingerprint, facial recognition, retina, and more. Hence multiple Bio Metric token types should be generated by a platform for the right risk context. I am reminded of the OpenSSO (STS) integration with Biobex for this purpose.

Thoughts on Token Technology Trends- No: 16

Similar to blog entry no 15, a TPM token can act as the initiating vector from which a SAMLtoken is generated by an STS and mapped to an OpenID token - like the one demo'd by wave technologies in 2009 at Digital ID world. This was an integrated demo using Ping STS. This same approach can be leveraged with any hardware token from CPU makers such as Intel and AMD.

Thoughts on Token Technology Trends- No: 15

One of the key forking factors for federation is the SIM card and the GBA/GAA tokens that are generated by a the Mobile Operators. To a certain extent for enterprises that are extending their services to the mobile devices, this bootstrapping architecture and AKA/Digest +SIM based GAA allows for some level of device and user context that can be exchanged via SAMLtokens and STS, and augmented with additional authN tokens if needed.

Thoughts on Token Technology Trends- No: 14

Now that we know that there can exist multiple Authentication types represented as a AuthN token for a subject, in those scenarios where there is Federation involved we have to have a good understanding of STS (secure token services) and the SAMLtoken (aka SAMLartifact) it generates. With recent developments at OASIS you should also note that SAMLartifact can also carry a XACML decision token (i.e., an AuthZ token), more on AuthZ token for the another blog entry.

Thoughts on Token Technology Trends- No: 13

Toeknized representation of the audit trails are also anoher key perspective to keep in mind - to ensure full loop back - for traceability and observability. For example: Audit Tokens similar to the ones generated by Solaris

Thoughts on Token Technology Trends- No: 12

Similar to the composite subject risk token, systems are capable of generating composite Resource Risk token as well. Darren Rolls the CTO of Sailpoint recently showed a demo that does risk ranking of resources based on multiple factors associated with the resource - including access review and access certification, the entitlements associated with the resource and more. The generated XML artifact about the risk rating of a resource can be tokenized - compressed, encrypted with metadata.

Thoughts on Token Technology Trends- No:11

There are two types of composite risk that can be calculated - one for a subject (typically a person - employee, partner, customer, etc.) - for example Securonix generates what they define as a SmartRanking artifact, which to me is a specialized XMLtoken representing the risk associated with a subject based on past and current behavior.

Thoughts on Token Technology Trends- No: 10

Another interesting trend is the Data Tokenization space (see paper). While data tokenization is to secure data (at rest and in transit) -the tokenized representation also has meta-data that classifies the data - such as PCI-DSS data, PII data, iTAR data and more. Which is also key to understand when we need to comply with regulatory requirements around data and data in the clouds! To me along with other firewall functions performed by a DB FW -this should be an add on capability. However today its typically an add on product.

Thoughts on Token Technology Trends- No: 9

Another key technology trend in this space is DRM and rights management expressions using XrML and the resulting XrML tokens (runtime licensing keys and artifact representing a resource access control function). This takes us to the topic of representing - rights, access, privileges, priority, entitlements and all AuthZ related functions as they relate to documents, databases, OS and applications + data - all expressed in Tokens - similar to XrML tokens - also allowing for  run-time representation of DAC, MAC, RBAC, DRM and more.

Thoughts on Token Technology Trends- No: 8

Another key technology trend in this space is the usage of Virtual Directory technology to create what is referred to as "computed tokens", such as Radiant Logic. VDS technology allows for the aggregation of associated attributes into a virtual view. From this virtual view lets say we can see a 100 attributes - we can easily define that if we see 90% of attribute match create a Green Token - 70-90% match a blue token - 50-70% match an orange token and below 50% a red token - all of which are computed token types around an attribute set. This functionality of computed tokens is very critical to understand as well.

Thoughts on Token Technology Trends- No: 7

One of they key value proposition of token typing is the fact that we also have the notion of a hard token and a soft token - a TPM (trusted platform module) or a SIM card can act as a Hard token with tamper resistant memory footprint and an identifier (unique to the device) which can act as the "Initiating vector" for storing other soft tokens and token types or combining the same if needed. This is a critical concept to understand in this space as well.

Thoughts on Token Technology Trends- No: 6

One of the extreme use cases according to some (not me) is to create an RBAC token or RBAC tokenization -- at runtime any tokenized artifact is a XML file with condensed attributes and meta-data. From that perspective RBAC profiles have been XML'ized for close to a decade now and therefore they can be tokenized as well into RBAC tokens. These tokens unlike AuthN token are considered to be Access Tokens (and an RBACtoken type is only one amongst many in this space). Please read the paper in the link above that describes the usage of RBAC tokens. Note: at run time this XML artifact (an RBACtoken) is also encrypted -so secure exchange is possible.

Thoughts on Token Technology Trends- No: 5

One perceived definition of token or a "security token" is that it is an authentication token (like a OTP token, Biometric token, SmartCard token or Kerberos token, etc). In our 100 entry description of the technology trends in tokens, tokenization and STS - we take a broader picture around tokens that go FAR beyond what is traditionally understood as token (authN tokens) - based on the definitions and token type description in the previous 4 entries. AuthN tokens are a critical piece however if we take an basket of tokens - they would represent only 10 to 20% of the token types. This again has to be kept in mind BIG Time!!

Thoughts on Token Technology Trends- No: 4

Tokens represent Assured Attributes -- i.e., The attributes are from authoritative sources validated by control functions performed prior to the token generation - for example; A posture token generated by a Cisco ASA solution is generated after the validation control function of  multiple attribute sets about a device. The same is TRUE for all Token Types - i.e., whether it is a AuthN token or Access Token or a SAML token it does not matter. Therefore one definition of a Token is that it is an "Active Abstraction of Assured Attributes". This understanding of a token is also very critical in terms of synergies and synthesis that it can bring to the table.

Thoughts on Token Technology Trends- No: 3

Another key trend to be noted is that there are many many token types in play within an Enterprise Security Architecture, namely;

• Public Tokens vs Private Tokens
• Standardized Tokens vs non-Standardized Tokens (SAML vs proprietory tokens)
• Authentication Tokens vs Access Tokens
• Subject Tokens vs Resource Tokens
• Integrity Tokens vs Trust Tokens
• Computed Token Types (many)
• Risk Tokens (for subjects and resources)
• Transaction Token Types (such as SWIFT Tokens)
• Network Token Types (such as Posture tokens and Path tokens)
• Decision Tokens and Obligatory Tokens 

I have listed nine token types here and there are many more. Each is a topic for an blog entry, but there should be clear understanding of what a token means and the types that they can belong to. An STS development kit should be robust enough to work with all these token types and more that can be custom defined.

Thoughts on Token Technology Trends- No: 2

The decoupling of Authentication and Sessions with Secure Token Services, is a another key technology trend. We are all familiar with many authentication mechanisms that generate a token type (bio-metric token or a SIM token, etc) - these independent Authenticating systems that authenticate an entity (user, device or application./service) generates a Authentication Token post successful Authentication and traditionally this was tightly tied to SSO services -such as WinSSO and Kerb token or Siteminder SSO and LDAP AuthN, etc. With the recent trend in terms of STS development - the secure token service is the service that accepts these tokens, creates a session token and does mapping and translaton of Tokens. Hence this technology trend in terms of decoupling Authenticating systems and Secure Token Services is a Key underlying technology trend that is extremely important to understand, tokens, token types, tokenization process, STS and more.

Thoughts on Token Technology Trends- No: 1

From this blog entry onwards I am challenging myself to post 100 entries and a 100 perspectives on Tokens, Tokenization and STS (Secure Token Services) - meaning each one is a unique perspective on this Technology Trend within the next 100 days !! So here it goes:

I grew up in chennai india - where every time we walked up to our family doctors clinic - we were given a token (since there were several dozen patients waiting in line). This token was cryptic - in a sense - since its had numbers and colors and certain markings in it. As i learn't later in life - the colors depicted - whether you were really sick or was it something that can wait, whether you were man or a woman, aged or young and more. The numbers reflected you turn - and there were multiple queues. Also in certain cases - a patient would be given preference either because they come from a privileged family (special tokens) or if they had called in advance (we typically walked in hoping  to have a wait time of less than an hr). Taking this analogy; a token has 5 characteristics - True for the Token relating to the Technology Trend we'll be discuss in these blogs as well;

• Tokens represent an Attribute Set (token types) -compressed or condensed - for example Perimeter host admission control solutions validate 60+ attributes about a device and then create a posture token (3 or 4 types - that reflects the Attribute sets)
• Tokens have some meta-data based on their characteristics (for example in the analogy above - green could mean sick boy, blue could mean sick girl, yellow sick adult man and red sick adult woman and more)
• Tokens are Cryptic - meaning that if you are not briefed in advance - all the substance in the token will mean nothing to you (in our technology trend they are encrypted and compressed -secure exchange)
• Tokens represent Attributes with some level of Assurance -Attribute Assurance - since they are based on successfull execution of some control function
• Tokens are generated at run time and have real time characteristics of a state of an Entity (entity can be subject or a resource or an action or condition) - real time representation of entities.

This is the basis for all the next 99 entries and therefore - it is imperative to  DIGEST this understanding of what Token represents!!

Architecurual Alignment with Access Control

I just completed my CISSP training last week and it was very interesting to note that amongst the 10 modules - Access Control is one and it includes - all three areas of IAM, "Identification", "Authentication" and "Authorization". If Authorization decisions at run time are also leveraging audit data (historical behaviors for example" - then we might add the topic of Audit as well to the overall Access CONTROL space. To me that leads to XACML:

• as the extensible XML based AC policy language, 
• the framework (PEP, PDP, PIP, PMP, etc), 
• the XACML request response paradigm (interfaces and integration), 
• the XACML profiles (such as RBAC profile) and,
• the SAML2XACML artifact that allows for the alignment of Authentication to Authorization at run time.

Just like how we saw the ID Federation (SAML) take off this past decade (2000-2010), this decade is the XACML decade  (2011-2020). If we view; applications plus services as one set of resources and data plus documents as another set of resources - the systems protecting apps/services are;

• XML firewalls (and we have support from IBM, Intel, Layer7 and majority of the vendors in this space that support XACML estensions
• RBAC systems (majority of the RBAC implementations extend via XACML-RBAC profiles)
• and Composite Risk Rating Engines (such as Sailpoint and Securonix) that generate XML artifacts that gets passed to a XACML PDP as a PIP

On the Data and Documentation side, we have an interesting scenario of some XACML vendors; the Top 5 being;
Axiomatic
Bitkoo
IBM
Oracle, and,
Nextlabs

beginning to support DB Firewalls and DRM systems(using XACML as a policy expression language) (plus integration into DLP).

All the NEP's (such as Cisco and Juniper) have the opportunity to create a specialized Network (perimeter) PDP - that unifies (UTM) - Deep Packet Inspection, with Packet FW, with Network Admission Controls and Intrusion Detection Systems - and generate Network Threat and Device Integrity Information (acting as a PIP) to the Enterprise Data+App PDP. This approach kinda ensures the REALIZATION of the Vision established by XACML as a Pervasive Policy Paradigm for an Enterprise Security Architecture !!

The AAA Aligned to AAA

I remember reviewing this IBM redbook on ESA a few years back and thinking about how an IAM (identity and access management) stack play's an important and critical role for Enterprise Security Architecture. I've just started a few weeks back at the Bank of America as a VP., Sr. IAM Architect in the Enterprise Security Architecture group. An amazing organization with a number of enterprise scale security projects going on (Six Sigma Security). I will have very little time to blog moving forward. My 1st paper at the organization along with a few others talks to the AAA behind AAA from Radius to an Integrated IDM Infrastructure. RADIUS was good a few decades back when we had a few remote dial up users and with almost all (employees, customers and suppliers) users in today's cloud, outsourced and highly mobile environments,  is remote and mobile accessing services under varying conditions (context), accessing services from a cloud data centers managed by operations outsourced to Asia and more., makes an Integrated IDM Infrastructure even more critical for distributed systemic security services;

AAA behind AAA:
Admission Control (Analysis, Acceptance and then Admission)
Authentication (Authenticity of credentials, Adaptive AuthN, etc)
Assertion (Assertion of tokens including authN Attestation and authN Assurance)
(all three making up the 1st A)
Attribute Aggregation (Assimilation of pre-authN, post AuthN, pre-AuthZ Attributes)
Authorization (entitlement data, privileges, permissions and more)
Access Control (run-time RBAC, ABAC, Risk, context driven, etc)
(all three making up the 2nd A)
Activity Monitoring (end to end log based RT monitoring)
Accounting (metering, measuring and billing)
Auditing (compliance reporting and certification)
(all three make up the 3rd A)

The paper will have functional decomposition of each of the 9 A's, inter-relationships between them, flow diags, etc. An amazing place to work at, an amazing area to focus on (IAM and ESA), an amazing team to work with.. Its going to be the best years of my career!!

Oracle'c Cloud Computing Center

Last week at OOW I had the chance to present "Context Aware Security for Cloud Control and Compliance" along with some friends at Verizon. It was an Amazing week since Oracle announced an array of products and solutions in support of our Cloud Computing Strategy. From ExaLogic EC -the cloud in a box solution for IAAS, PAAS and SAAS, to the next generation of ExaData for Storage AAS and DB AAS, to the Niagara T3 CMT processors and systems based on T3 (ideally suited for Cloud Security and Control Applications - that are parallel in nature -see paper). There are a number of excellent papers and webcasts here that discuss everything cloud;
Cloud Strategy
Cloud Computing and EA
Cloud Management
Cloud API
Public vs Private Clouds
and more..

My next dozen plus blog entries will be around "Context Aware Security for Cloud Control & Compliance".

The Intersection of IDM and IN

My 2nd paper is around the integration and intersection of different Intelligence data both Network facing, IT facing and Business facing around a common identity management layer. Mobile Cloud Operators have unique advantages in the Cloud Control and Compliance space due to the visibility and transparency they have on both ends. Here is a nice writeup on the Intersection of IDM and BI from a GRC perspective. Oracle with its complimentary solutions around an Integrated Identity Infrastructure that includes DB Security, MDM, GRC, BI and NI products is again well positioned here. Its already possible to Integrate Network Intelligence and Business Intelligence with a common Identity Infrastructure today (to a certain extent) and since the Cloud Paradigm converges and collapses the Business and Network layer into ONE, any Cloud Initiative will require this end to end IN integration. This approach is also facilitated by SEIM software (such as the ones from our partner LogLogic) that collects Logs end to end and applies Logic on top for Security Events and Information.

Charging for Cloud Computing Services

Oracle is a market leader in terms of Integrated Identity Infrastructure Implementations in Telco's (mobile operators) worldwide. These Telco's are all gearing up for Mobile Cloud Computing initiatives.. I just delivered a Keynote at the SIMposium 2010 in Rome yesterday and folks here clearly view SIM+SCWS+Secure Contained Client Code+JC 3.0 as a PEP (policy enforcement point and a programmable end point) as the ideal Cloud Client. Another important perspective when offering SAAS, PAAS, IAAS, etc., is the flexible, open, robust charging and billing models that are required for all the IP Cloud Services. Here is an excellent presentation via webex from Paul and Elisabeth on how well Oracle's BRM is positioned for these large scale Cloud Initiatives from a Charging and BRM perspective - and how well they can support different business models and revenue recognition models. I am working on a series of 5 papers (that would eventually transition into my "Identity and Trust" book on - Cloud Control and Compliance with a number of Industry coauthors) and the 1st one is on the significance and importance of an Integrated ID Infrastructure from a charging and billing perspective for Cloud Services. The obvious ones are;

• Mediation between Operator as an IDP and ASP/SAAS as a SP is facilitated with federation
• Revenue Assurance is aligned to ID Assurance levels
• Mobile wallet is a PEP for a PDP
• Fraud Detection & Risk Based AC for Billing - Transaction level AAA
• Pre-pay, post pay, pay per use and other pricing models - aligned to Roles and Responsibilities
• Integration with AAA, Radius, Diameter, etc
• Access Control - DRM -content/IPTV/services tied back to payments
• Log Data from III for non-repudiation and assurance
• Consolidated Converged Charging is USER/ID Centric

A Critical Cloud Control partner -Vordel

Vordel, Oracle's key partner for Cloud Control & Compliance area, did an excellent presentation at Telco Cloud 2010 last week, and will be at the E-Identity event next week as well. Check out the joint presentations and white papers, discussing the integration between Vordel's Cloud Control product Oracle's Identity Infrastructure products, Oracle DB and Oracle's Enterprise Manager. There are both common Telco and NEP customers who will benefit hugely with this Integrated Approach for their Cloud Control Initiatives!!