Shibboleth Developers

["David L. Wasley" <>]

Steven, I am strongly of the opinion that asking the portal to cache 
and forward attributes is a bad model for 2 significant reasons:

1) It violates the "minimum necessary information" model - the portal 
"knows" more that it needs to and this could result in a compromise 
of users' privacy.  Suppose we get to a point where my bank is my 
Identity Service Provider (Origin) and I want it to release my charge 
account number to vendors - should the shopping portal cache (cash?) 
that information?

2) Enforcement of the AA's attribute release policy must be extended 
somehow to the portal so that the user's preferences, etc., are 
respected.  This adds unnecessary complexity.

I believe there is a very straight forward way to deal with the 
portal N-tier problem.  Attached is the proposal I wrote up long ago 
- I've not heard feedback that would suggest it isn't workable.

It avoids the need for caching of attributes in the portal since it 
enables the web service to communicate directly with the AA.

        David

PS: I'm sorry I couldn't make the recent Shib design con call.  I'll 
be sure to join you next time.
-----
At 4:23 PM -0400 on 9/24/03, 

 wrote:

> 18-24 months ago, we had a quite a bit of discussion about how to 
> integrate Shib and portals (or, more specifically, uportal). At that 
> time, we stopped the discussion, because 1) the problem is hard, and 
> 2) it was clear that we wouldn't be addressing this scenario with 
> the initial implementation.
>
> Now, we're begun discussions about the next version of Shib, and 
> we're once again looking at this question.
>
> So far, in conference calls, we've managed to revisit and tour much 
> of the same landscape we explored all those many months  ago. One of 
> the popular discussion items is the basic model -- we go round and 
> round on whether the portal can cache credentials and attributes  or 
> not. Should the portal obtain and hold a superset of all the 
> attributes required by the various channels it contains, and pass 
> these attributes on to the channels, or  should each channel that 
> needs shib attributes make a separate request back  to the AA?
>
> So far, there's been no obvious answer. One recent breakthrough, 
> tho, has been to look at this from the trust perspective. And to ask 
> "are there channels (applications) that would  not trust the proxy 
> to obtain and forward attributes on their behalf?". We can imagine 
> that there *might be* intra-domain applications with this 
> constraint; its easier to  imagine inter-domain applications with 
> this constraint. But, while we can imagine these situations, we also 
> see that virtually all current portal deploys do cache credentials, 
> and this seems to be  quite  acceptable to campuses. We certainly 
> don't hear lots of screams about this.
>
> And, so far, we don't have a concrete use case in front  of us where 
> the channel  WILL NOT use forwarded attributes......
>
> Can someone think of one?

Attachment: draft-Wasley-Shib-portal-02.pdf
Description: Adobe PDF document