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
