RE: [higgins-dev] Proposedupdates toHiggins ArchitecturediagramperAustin

["Brian Carroll" <BCarroll@xxxxxxxxxx>]

I'll defer to Mike's opinion on this, but my reaction is: we could
consider Attribute-to-Claims mapping from a broader perspective.  At
present attribute-to-claims mapping occurs in the STS to map claims in a
WS-Trust RST to the corresponding attributes that the IdAS and
ContextProvider expose.  In Mike's newly refactored STS, I believe such
mapping has been moved to custom exit/extension points.  
 
It would seem that we would want to have a uniform mechanism (and
interface) to all Attribute-to-Claims mapping, whether it is called by
i-card providers or the STS.
 
>From my observations of the industry, the need for "custom claims
mapping" is becoming common.  The need for such mappings a real one,
simply due to differences in naming that are sematically the same, or
for more complex mappings where transformation is required (e.g. "Date
of Birth"  to "Age" or "Over 21").   
 
I recommend we use a common mechanism for all Attribute-to-Claim
mapping.  
 
Regards,
Brian

________________________________

From: higgins-dev-bounces@xxxxxxxxxxx
[mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Paul Trevithick
Sent: Tuesday, May 08, 2007 9:09 AM
To: 'Higgins (Trust Framework) Project developer discussions'
Cc: higgins-dev-bounces@xxxxxxxxxxx
Subject: RE: [higgins-dev] Proposedupdates toHiggins
ArchitecturediagramperAustinF2Fdiscussions



Raj would like to see us introduce a new Component that i-card providers
could optionally use to do what he calls attribute to claims
transformation. 

 

Here are the benefits(+)/costs(-) as I see them:

+ allows an i-card provider to not be dependent on IdAS (i.e. using an
IdAS CP to perform this transformation)

- introduces complexity: another component in the architecture, another
code base to maintain

- defining and maintaining a new interface (this might not be true
depending on the design)

 

Are there other benefits?

Other costs?

 

-Paul

 

________________________________

From: higgins-dev-bounces@xxxxxxxxxxx
[mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Nataraj Nagaratnam
Sent: Tuesday, May 08, 2007 11:50 AM
To: Higgins (Trust Framework) Project developer discussions
Cc: Higgins (Trust Framework) Project developer discussions;
higgins-dev-bounces@xxxxxxxxxxx
Subject: Re: [higgins-dev] Proposedupdates toHiggins
ArchitecturediagramperAustinF2F discussions

 

Context (Attribute) Providers could act as ClaimsProvider. But saying
Context(Attribute)Provider is the only way to get claims and only
ClaimsProvider for Higgins .. is the limitation I would like to see if
we can avoid.



 "Tom Doman" <TDoman@xxxxxxxxxx>



"Tom Doman" <TDoman@xxxxxxxxxx> 
Sent by: higgins-dev-bounces@xxxxxxxxxxx 

05/08/2007 11:18 AM 

Please respond to
"Higgins \(Trust Framework\) Project developer discussions"
<higgins-dev@xxxxxxxxxxx>

 

To

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



cc





Subject


Re: [higgins-dev] Proposedupdates toHiggins ArchitecturediagramperAustin
F2F discussions

 






Yep, not sure Duane was saying that wasn't true also ... but I digress
...  In Higgins, we already have Context Providers which could act as
Claim Providers as well.  Through the JavaScript CP, JavaScript could be
used to transform, remove, and\or create claims from the Digital
Subjects returned.  Call them Digital Identities at that point but the
interface conveniently stays the same.  BTW, tangentially, JavaScript is
the only implemented choice so far, but we could use any number of
policy or other languages in a Context Provider to achieve the same
thing.

Tom

>>> Anthony Nadalin <drsecure@xxxxxxxxxx> 5/8/2007 8:41 AM >>>
Well not always true as there are claims that are or can be attibutes
like birthdate

-----------------
Sent from my BlackBerry Handheld.


----- Original Message -----
From: "Duane Buss" [DBuss@xxxxxxxxxx] 
Sent: 05/08/2007 08:20 AM
To: "discussions', 'Higgins (Trust Framework) Project developer"
<higgins-dev@xxxxxxxxxxx>
Subject: RE: [higgins-dev] Proposed updates toHiggins
ArchitecturediagramperAustin F2F discussions



    Claims and attributes are different, and one should always be able
to tell the difference between the a claim and an attribute.  However I
don't believe that necessitates that they must be represented by
different objects and accessed via different interfaces.

    As an example consider a relying party, it may have multiple
authentication methods, some of which present tokens containing attested
claims, some of which result in presenting an identity and credentials.
When it is time to authorize  the client, the relying party implementer
is faced with multiple possibilities: different authorization paths
depending on the authentication mechanism, transform the identity and
credential to claims (via the Higgins STS of course), or transform the
external claims to their internal attribute equivalents.

    The line between claims and attributes becomes especially blurry
when we start transforming claims.   At that point is it still a claim,
or is it now an attribute, or is it some third thing?

    I personally believe that there will be instances where claims and
attributes will need to coexist and both be part of trust and
authorization decisions.   That the evaluation engine at that
authorization decision point doesn't want to have to have different
objects, interfaces ,or models for accessing these properties, that
would be madness.

    Once again, claims and attributes are different, and one should
always be able to tell the difference between the a claim and an
attribute.  I agree that IdAS may not be 'THE' source of claims or
attributes, but there should be a common interface that people can use
to operate with either type of property.

Duane

>>>
From: Nataraj Nagaratnam <natarajn@xxxxxxxxxx>
To:"Higgins (Trust Framework) Project developer discussions"
<higgins-dev@xxxxxxxxxxx>
CC:<higgins-dev-bounces@xxxxxxxxxxx>, "'Higgins (Trust Framework)
Project developer discussions'" <higgins-dev@xxxxxxxxxxx>
Date: 5/8/2007 7:26 AM
Subject: RE: [higgins-dev] Proposed updates toHiggins
ArchitecturediagramperAustin F2F discussions

Digital Subject contains list of attributes not claims ! Like we
discussed many times in the past and also in the recent F2F, claims
could be based on attributes of DigitalSubject, they could be derived
from attributes (but not necessarily the attributes themselves), or
could be derived from some other claim assertions from other IPs/RPs

I would like us to discuss this ... as we continue to treat attributes
and claims to be synonymous and IdAS to be 'THE' source of claims as
well. I am not sure that is always true.

Raj


"Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>


"Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>
Sent by: higgins-dev-bounces@xxxxxxxxxxx 
05/08/2007 08:48 AM Please respond to
"Higgins \(Trust Framework\) Project developer discussions"
<higgins-dev@xxxxxxxxxxx>


To
"'Sergey Lyakhov'" <slyakhov@xxxxxxxxxxxxxx>


cc
"'Higgins \(Trust Framework\) Project developer discussions'"
<higgins-dev@xxxxxxxxxxx>


Subject
RE: [higgins-dev] Proposed updates to Higgins
ArchitecturediagramperAustin F2F discussions




SergeyL wrote:
>
> > But thinking out loud here...if I were designing the CPIP I think I
> would
> > have stored within the CPIP object itself a URI field: "<ContextId>
/
> > <SubjectId>", where ContextId points to, say, a Jena-backed Context.
And
> > SubjectId to a DS within it (the SubjectId can be null if there is
only
> > one
> > DS in the Context, BTW).
>
> Yes, IdAS-based CPIP is implemented in this way. Personal I-Card
contains
> a
> reference (ContextId + SubjectId) to a Digital Subject which contains
a
> list
> of claims ().

Good.

> On the other hand, STS shouldn't use this reference, if we
> will need to develop some non-IdAS based CPIP.

Why do we need to develop a non-IdAS-based CPIP?

> There is a method
> ICard.getClaims(), and it could be used by STS in case of Personal
ICard.
>
> Thanks,
> Sergey Lyakhov
> ----- Original Message -----
> From: "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>
> To: "'Higgins (Trust Framework) Project developer discussions'"
> <higgins-dev@xxxxxxxxxxx>
> Cc: <higgins-dev-bounces@xxxxxxxxxxx>
> Sent: Tuesday, May 08, 2007 2:45 AM
> Subject: RE: [higgins-dev] Proposed updates to Higgins Architecture
> diagramperAustin F2F discussions
>
>
> >
> >
> > Mike wrote
> >>
> >> Paul,
> >>
> >> We are trying to figure out a few things wrt attributes for
"personal"
> >> i-Cards.
> >> In "managed" mode, the STS pulls attribute values for claims from a
> >> Context via Context Provider/IdAS.
> >> In "personal" mode, it is unclear where the attibute (and master
key)
> >> values are - are they in the i-Card Store?
> >
> > SergeyL has been designing and developing the CardSpace Personal
i-card
> > provider (CPIP). So he should answer rather than I. The doc he wrote
> here
> > [1] is extremely vague (and should be fixed).
> >
> > But thinking out loud here...if I were designing the CPIP I think I
> would
> > have stored within the CPIP object itself a URI field: "<ContextId>
/
> > <SubjectId>", where ContextId points to, say, a Jena-backed Context.
And
> > SubjectId to a DS within it (the SubjectId can be null if there is
only
> > one
> > DS in the Context, BTW). That way I could pass this
ContextId/SubjectId
> > reference along in the RST to the TS and the TS could open this
> > ContextId/SubjectId. I would have separately developed a parser to
> import
> > the MSFT-defined personal i-card format. And I'd have separately
> developed
> > a
> > generator to export to this same format.
> >
> >> It seems as if there is a need for the iCard Store for personal
i-Cards
> >> to
> >> be accessible via Context Provider/IdAS.
> >> If so the lines aren't drawn to reflect that.
> >
> > As mentioned I'm assuming that the runtime storage of CPIP
attributes is
> > in
> > IdAS. So only the existing blue link from the CPIP i-card provider
to
> the
> > IdAS Component is required.
> >
> > [1] 
http://wiki.eclipse.org/index.php/CardSpace_Personal_I-Card_Provider 
> >
> > <snip>
> >
> > _______________________________________________
> > 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 

_______________________________________________
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



**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.