Once again, we turn to the DD. In fact, we’ll use our old friend <security-constraint> for both confidentiality and integrity by adding an element called <user-data-constraint>. And when you think about it, it makes sense—if you’re thinking about authorization for a resource, you’re probably going to consider whether you want the data transmitted securely.
This is the default, and it means there’s no data protection.
The data must not be changed along the way.
The data must not be seen by anybody along the way.
NOTE: although not guaranteed by the spec, in practice virtually every Container uses SSL for guaranteed transport, which means that both INTEGRAL and CONFIDENTIAL do the same thing—either one gives you both confidentiality and integrity. Since you can have only one <user-data-constraint> per <security-constraint>, some people recommend you use CONFIDENTIAL, but again, it will probably never matter in practice, unless you move to a new Container that doesn’t use SSL for guaranteed transport.