Print

Print


> you can't have a seamless transition from a
> non-privacy-preserving to a privacy-preserving identifier scheme
that's the point though. The identifiers are privacy-preserving but the
service is still in non-privacy-preserving mode. That's why they ask for
private information that the privacy-preserving identifier fails to
provide.

A seamless approach would be to transport the required information in
attributes and let the SP do the account linking, instead of foisting it
all on the hapless user, who is making the bridge between shibboleth and
the "real world" of service providers who are used to receiving private
information before granting access.

> And of course setting up account-linking as above would be work for
> somebody.
and confusion for the user who has two accounts to sort out. Albeit a one
off event but something they don't associate with shibboleth.

Alistair



-- 
mov eax,1
mov ebx,0
int 80h

>> I can't see any way for providers to match up these two credentials to
>> the single account. So you end up re-creating all your alerts/settings
>> that you've set up with your normal athens account. You have to do it
>> all again if you come in via shibboleth.
>
> Some applications have moved to federated access via an account-linking
> step.  In this case a user might go to an Athens-run site that is
> protected via Shib, signon via their home institution IdP, then signon
> again via the Athens userid, linking the two.  This info could be made
> available to anyone who needed it.  Of course for this to be useful the
> user identifier provided to this service via Shib would have to be
> something sharable, ie not the usual targetedID implementation that is
> per-service.
>
> I guess the point is that you can't have a seamless transition from a
> non-privacy-preserving to a privacy-preserving identifier scheme.  If the
> seamless transition is important perhaps the privacy features are less so.
>
> And of course setting up account-linking as above would be work for
> somebody.
>
>   - RL "Bob"
>