|
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.
On 29-Nov-07, at 6:25 PM, Anthony Nadalin wrote: Here is the general policy language description that drives the enhanced privacy support in Higgins http://wiki.eclipse.org/Relying_Party_Security_Policy.
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
<graycol.gif>Phil Hunt ---11/28/2007 03:41:08 PM---Tony...what are you referring to exactly?
<ecblank.gif>
From: | <ecblank.gif>
Phil Hunt <phil.hunt@xxxxxxxxxx> | <ecblank.gif>
To: | <ecblank.gif>
"Higgins (Trust Framework) Project developer discussions" <higgins-dev@xxxxxxxxxxx> | <ecblank.gif>
Cc: | <ecblank.gif>
higgins-dev-bounces@xxxxxxxxxxx | <ecblank.gif>
Date: | <ecblank.gif>
11/28/2007 03:41 PM | <ecblank.gif>
Subject: | <ecblank.gif>
Re: [higgins-dev] Notes from a teleconf meeting wrt IGF |
Tony...what are you referring to exactly?
Phil Hunt
Oracle
On 28-Nov-07, at 1:00 PM, Anthony Nadalin wrote:
Not seeing any value with IGF, we already have claims and policy that can express what IGF is supposed to be able to express, so maybe the IGF folks can just pickup what has been done with defining the claims.
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
<graycol.gif>"Jim Sermersheim" ---11/28/2007 02:45:24 PM---To try and push ahead on fleshing out what it would take to consume Higgins by the IGF, or implement parts of it in Higgins, we
<ecblank.gif>
From: | <ecblank.gif>
"Jim Sermersheim" <jimse@xxxxxxxxxx> | <ecblank.gif>
To: | <ecblank.gif>
<higgins-dev@xxxxxxxxxxx> | <ecblank.gif>
Date: | <ecblank.gif>
11/28/2007 02:45 PM | <ecblank.gif>
Subject: | <ecblank.gif>
[higgins-dev] Notes from a teleconf meeting wrt IGF |
To try and push ahead on fleshing out what it would take to consume Higgins by the IGF, or implement parts of it in Higgins, we had a chat on the phone with Phil Hunt. Primarily, the call was geared toward sharing descriptions of architecture (understanding how IdAS works and understanding the IGF architecture).
I put notes here http://wiki.eclipse.org/20071128_IGF_teleconf_notes
which are pointed at from here http://wiki.eclipse.org/IGF_Integration
which is pointed at from here http://wiki.eclipse.org/Identity_Attribute_Service
I'll start a new thread (continuing an old one) on Idas API extensibility which was one of the work items that came from the call.
Jim _______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
<graycol.gif><ecblank.gif>_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
<graycol.gif><ecblank.gif>_______________________________________________ higgins-dev mailing list
| 