[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