Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [higgins-dev] Notes from a teleconf meeting wrt IGF

Phil, this document is as you point out partial as it was taken from a much larger scope document (IDEMIX) that we have and was specifically scoped to the RP, but the overall document and concept behind IDEMIX is not just RP. The policy aspects cover all parties involved, IdP, Identity Agents and RP and it not limited to WS-Federation, we use the WS-Policy constructs since that is a standards base policy framework. We also wanted to fit with the Claims framework to be able to expand upon beyond what Cardspace has done, yet be compatible

In our analyses the "AAPML" spec is a bit like EPAL profile in XACML and "CARML" spec is like a token request specification,



Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122

Inactive hide details for Phil Hunt ---11/30/2007 02:38:33 PM---Thanks for the link.Phil Hunt ---11/30/2007 02:38:33 PM---Thanks for the link.


From:
Phil Hunt <phil.hunt@xxxxxxxxxx>

To:
"Higgins (Trust Framework) Project developer discussions" <higgins-dev@xxxxxxxxxxx>

Cc:
igf-dev@xxxxxxxxxxxxxxxxxxxxx

Date:
11/30/2007 02:38 PM

Subject:
Re: [higgins-dev] Notes from a teleconf meeting wrt IGF



Thanks for the link.

The document referenced (Relying Party Security Policy) is definitely important. But at this stage seems preliminary since it implies only a single protocol scenario. [aside...the ontology links are broken]  By this I mean, we need to take that document and further expand on it.

The major component of policy referred to in Relying Party Security Policy document is what I would call relying party web policy. It describes only what information is needed to be transferred and how it is to be transferred (i.e. WS-SecurityPolicy). IGF doesn't conflict with what already exists in WS-SecurityPolicy, but rather adds more context and more information. 

IGF answers more of the following issues:
* How do attribute authorities (e.g. Identity Providers) that hold information decide to accept and release information?  
* Consent can raise transactional conditions that must be accounted for. E.g. two partners might agree on how to generally share information enabling a general flow. However, user-consent may indicate special conditions (e.g. suppression or filtering of specific claims, denial of claims, or special conditions such as "do not propagate").
* Context - there is a greater need in fine-grained authorization to fully define the context under which information is released. This means being able to transmit both the credentials of the application, the end-user involved, and potentially a transaction name and purpose (e.g. legal context).
* From an consuming application perspective (relying party), WS-SecPol describes attributes and how they are to be delivered. It does not document the applications intended use of data. CARML provides additional meta data gives the Attribute Authority more context to approve the release of information. CARML and WS-SecPol definitely have a relationship and should support each other. The nature of that relationship needs to be defined more clearly.

http://wiki.eclipse.org/Relying_Party_Security_Policy is a good early document and useful for discussion within the Higgins framework and within IGF. It represents the case where IGF is applied in a WS-Fed scenario.  I'd be happy to reference this material from the openLiberty site if you like. I think it is important that we support and build on these ideas.

Phil Hunt
Oracle


On 29-Nov-07, at 6:25 PM, Anthony Nadalin wrote:
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev

GIF image

GIF image

Back to the top