[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [higgins-dev] Proposedupdates toHiggins ArchitecturediagramperAustinF2F discussions
|
Oh, okay, sounds fair to me.
>>> Nataraj Nagaratnam <natarajn@xxxxxxxxxx> 5/8/2007 9:49 AM >>>
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@xxxxxxxxx
m> To
Sent by: "Higgins (Trust Framework) Project
higgins-dev-bounc developer discussions"
es@xxxxxxxxxxx <higgins-dev@xxxxxxxxxxx>
cc
05/08/2007 11:18 Subject
AM Re: [higgins-dev] Proposedupdates
toHiggins
ArchitecturediagramperAustin F2F
Please respond to discussions
"Higgins \(Trust
Framework\)
Project developer
discussions"
<higgins-dev@ecli
pse.org>
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
