The first is from Felix Gaehtgens of Kuppinger Cole. Felix talks about why IGF is becoming more important in today's increasingly global society...
[...] For a starter, many enterprises still have private identity data stored in many different data stores. Even though the trend is to minimise the number of “data silos” (places where identity data is stored), the reality is still that data can be found in many places. This creates a problem in our globalising society, where the HR department might be run in one country, and the support desk in another, and a myriad of services being outsourced yet to other locations. How can one ensure that the flow of data is controlled in such a way to ensure that all privacy laws are being complied with? Another example could be a federated environment of several suppliers working together in order to process an order. The order is received by company A, which then sends out several orders for parts to companies B1, B2 and B3, who then ship everything to company C that assembles everything and uses company D to ship out the finalised order to the customer.Felix goes on to accurately describe CARML and AAPML and concludes:
So why another set of protocols? Isn’t this already addressed in some other standards? Liberty’s ID-WSF springs to mind, or SAML 2.0’s AttributeQuery, SPML, or even - to a certain extent - WS-Trusts Security Token Service. However, CARML and AAPML bridge a very important gap that is not addressed anywhere else: not how to request and receive attributes, but to express the need and purpose of identity data, and on the other side the allowed use and conditions for its consumption. IGF’s framework conceptually fits seamlessly into architectures harnessing today’s frameworks and picks up where CardSpace, Higgins, Bandit and WS-Trust, leave off.The second bog post is from Sajjad, who writes:
IGF's framework conceptually fits seamlessly into architectures harnessing today'sI like to put sum it up this way - most of today's protocols deal with the "how" and "what" information should be transferred - the technical mechanisms for transferring information. For this, there are indeed many mechanisms each stressing different security objectives. IGF's role is to really talk about the "why", "when", "where", and for "whom" information should be consumed, shared, used, and updated.
frameworks and picks up where CardSpace, Higgins, Bandit and WS-Trust,
leave off.
No comments:
Post a Comment