OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: URI security problems


Nigel,

> In my opinion, a linkage scheme based on hashing the object to generate
> its ID is better, because it imposes fewer requirements on issuers and
> makes the scheme more robust. You can't accidently reuse your own or
> somebody
> elses ID, unless the hash has collided. It also serves as an additional
> check
> on the integrity of the linkage (incase you have accidently trusted a "bad"
> issuer
> generating IDs that are being used by another issuer). The latter may be
> important if
> you have many trust relationships.

That's is very a valid argument.  i.e. the problems are not on crypto-level but
on a higher, application-level/security-service level.  I personally have severe problems
with the S2ML-way of doing things when you have *many-to-many* relations.  IMO these layered
assertions have very little meaning in those contexts. What are the relations between the different
issuers making a complete credential BTW? Looks like a source of tons of troubles.
Here I think we have a major S2ML scoping issue.  Since there is nothing wrong with
the original S2ML constructs for closed scenarios (like some portals), I propose that
additional (separate) constructs are created for scenarious of the kind that
I have referred to earlier.  Such credentials only have one issuer and no references to
assertions.   They typically only contains a reference to an arbitrary "Payload" document in an
alien namespace.  The latter would (if ever required) even allow Entitlements to be a part of such a
Payload document!

Anders

Anders



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC