Assurance

["Curry, Warren" <>]

I would like to see the case of the null value handled.  This is the case 
that is many individual account at UF will not attain Bronze or Silver 
certification.  They run in the same IdP and could attempt to access a 
service with null value.  It would be a better data solution to provide for a 
value when the assertion is null.  This easily distinguishes an 
implementation or data error vs a user who has not been given an InCommon IAP 
level of Assurance.  

This would be a wise and very good direction to proceed in my opinion. 

Warren 

-----Original Message-----
From: 

 
[mailto:]
 On Behalf Of Cantor, Scott
Sent: Monday, September 19, 2011 6:21 PM
To: 

Subject: Re: [Assurance] Assurance InterOp: Notes/AIs from 9/19

On 9/19/11 5:08 PM, "Ann West" 
<>
 wrote:
>
>To help migrate services into a common framework, we should define a null
>assurance value, so that empty requests are not the common case.
>Requiring  "ordinary" as class would get folks going and at least
>asserting something. Campuses could also assert several assurance values
>upon the SP request---the order of the values matter in the process given
>the first one that matches is triggerable.

That was more of a "could" than "should". It was just a suggestion, but is
a lot of work to end up saying "I'm telling you nothing useful".

-- Scott