Subject RE: VO challenges - article
From "Jones, Mark B" <Mark.B.Jones@xxxxxxxxxxx>
Date Tue, 27 Oct 2015 01:09:18 +0000

> >> My own opinion is that once you give up on using federation for
> >> authorization data, it's inevitable that authentication will follow.
> >>
> >> If the IdPs don't want to be in the buisiness of helping with access
> >> management for the applications using their service, then they won't
> >> have a service to worry about within a short span of time.
> >>
> >> -- Scott
> >
> > [Mark] I completely disagree.  From the relying party perspective I
> > have no use for authorization data from an IdP.  Authentication is where 
> > the
> value is.
> > Just give me a reasonable identifier.
> There's at least one real world use case for authorization data from the VO 
> /
> RP perspective, and that's initiating a deprovisioning process. For example, 
> if a
> VO participant loses a university appointment, that may in turn change or
> remove their eligibility for participating in the VO.
> This also implies attributes for provisioning, but during onboarding there 
> is
> incentive for an enrollee to demonstrate (somehow) a suitable affiliation. 
> No
> similar incentive exists for offboarding. ("Oh yeah, I'll remember to tell 
> you
> when I quit my job.")
> It would probably be helpful to this use case for R&S to be expanded to 
> include
> eduPersonAffiliation...
> -Benn-
I don't see 'de-provisioning' as a valid activity for an external service. 
The relying party should have no expectation of being informed of changes in a 
user's status.  In my opinion, the user must continue to demonstrate 
eligibility or lose access.

Attachment: smime.p7s
Description: S/MIME cryptographic signature