I ran it through a use case. Point taken. I hereby withdraw that comment. There's a case for separation (by the expected LoA of the attribute from a particular provider) just to assist with the comparison and eventual decision by the SP, but it's relatively trivial in the scheme of things. Cheers Colin -----Original Message----- From: dg-am-bounces@kantarainitiative.org [mailto:dg-am-bounces@kantarainitiative.org] On Behalf Of Rainer Hoerbe Sent: Monday, 5 March 2012 5:12 p.m. To: Colin Wallis Cc: dg-am@kantarainitiative.org Subject: Re: [DG-AM] AM Report Clean up (RE: REMINDER & AGENDA - DG-AM call, 28-Feb-2012) Am 05.03.2012 um 01:32 schrieb Colin Wallis:
<< RH: What I question is the need to have different terms and roles for providers of a plain and of derived attribute. What function would we miss or what risk increase if the identity attribute provider would serve derived attributes together with pristine attributes?>>
CW: Needed because they are slightly different roles and the these attribute providers are not necessarily the same for all the reasons stated. >From the SP/RP's viewpoint, it would be easier to have this distinction IMHO.
Can you provide a use case? I am still missing the point - Rainer _______________________________________________ DG-AM mailing list DG-AM@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-am ==== CAUTION: This email message and any attachments contain information that may be confidential and may be LEGALLY PRIVILEGED. If you are not the intended recipient, any use, disclosure or copying of this message or attachments is strictly prohibited. If you have received this email message in error please notify us immediately and erase all copies of the message and attachments. Thank you. ====