> I think this mostly demonstrates that Microsoft haven't *really* quite
> grasped the concepts of Federated Access Management yet (I mean
> collectively; I'm sure there are some individuals within the behemoth
> that understand them well, but...).
I can assure you that they understand very well about the use of
attributes for authorization. The problem they're facing with this
service is that lots of sites that they want to work with are not able to
assert student affiliations, only member. Microsoft's interest with this
program is getting software into students' hands. So they can enforce the
policy strictly, and cause lots more students to have to use the backup
method (via ICSI, a student-travel company), or they can be loose about
their policy, and let in some number of non-students. They're choosing,
for the rollout period at least, to be permissive. You might well make
the same decision in their position.
> They've got as far as doing the devolved AuthN bit, but not the (more
> difficult?) bit about federated (and con-federated) AuthR. Not too
> surprising, as at a global level there's still not much complete working
> inter-federation, and not complete agreement on the attribute sets and
> values that we all recognise as 'a student'.
I think the burden is actually on our community to be much more consistent
and pervasive in our ability to do straightforward things like assert a
student affiliation. The alternative is that the federation concept
doesn't succeed in this area and we continue indefinitely with students
faxing their ID cards to vendors to show that they're students.
- RL "Bob"
|