[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [higgins-dev] Proposed updates toHiggins ArchitecturediagramperAustin F2F discussions
|
Some of the use cases I can think of...
- Token transformation - one token comes in w claims, and we need to generate another set of claims from that. It could be just a token transformation wrt format.. in other cases, it could be transformation of claims themselves.
Idemix is one example where certain claims are masked.
I-card looks like one such thing - you have a card with claims and trying to get another token based on that card.
- Claims to be asserted could come from different services/sources other than identity stores
Attributes like profiles, preferences, etc could be managed by users, administrators. But there are certain assertions like authorization capabilities, or entitlements - these are asserted by authorities (think of this as an authorization engine issuing what a subject could do). Paul 'can purchase gifts worth upto $100', ;can reserve a conference room', 'can bid upto $1000' ... etc are some claims that could be in a token. These claims are not in identity stores like LDAP necessarily. Typically these are based on policies and could be asserted from different sources (be it authorization service, some thing else).
Another example is reputation. One can argue reputation is an attribute of DS. One could argue that it is generated based on some other rules in a reputation system and not managed as an attribute necessarily
These could be from another STS, another IdAS, some other system using authorization/entitlement protocols, etc. To allow for the possibility, i feel it is good to architect it for that possibility .. instead of asking everyone to treat every claim type to be an attribute.
Thinking about it.. maybe it comes down to who manages these 'things' - attributes are managed by administrators or users or others with appropriate authority; claims on the other hand are issued/asserted based on managed attributes. I tend to think that not
all claims are managed per say ... it could be issued/asserted dynamically, or transformed from one to anther. Runtime interface could be similar (not sure if same).. but way these are managed aren't so. So, building tools for IdAS does not automatically imply any claim could be managed.
Attributes could have a source like we had discussed in the past. Claims have an authority backing the claim (it could be self asserted) to whom we may be able to go back and validate.
trust me.. I would very much like to get usage of IdAS.. but trying to make sure we do not limit ourselves in what could make up the DIs.
-Raj
![Inactive hide details for "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>]()
"Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>
"Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>
Sent by: higgins-dev-bounces@xxxxxxxxxxx
05/08/2007 12:20 PM
Please respond to
"Higgins \(Trust Framework\) Project developer discussions" <higgins-dev@xxxxxxxxxxx> |
|
|
From: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Nataraj Nagaratnam
Sent: Tuesday, May 08, 2007 9:26 AM
To: Higgins (Trust Framework) Project developer discussions
Cc: higgins-dev-bounces@xxxxxxxxxxx; 'Higgins (Trust Framework) Project developer discussions'
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,
From IdAS
they could be derived from attributes (but not necessarily the attributes themselves),
Using IdAS transformation CP
or could be derived from some other claim assertions from other IPs/RPs
This might be the part that I don’t understand. From where (what interface) would these “claim assertions” be retrieved? Are you envisioning another IdAS-like data abstraction layer with a pluggable interface? If so it sounds like we’re reinventing IdAS.
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.
You may be right. I’m trying to understand the use case and/or data flow.
Raj
![Inactive hide details for "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>]()
"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> |
|
|
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
