Hannes Tschofenig wrote:
> Here is a review by Andreas Pashalidis:
>
> ----------------------
>
> Here are a few small comments:
>
> "trait-based" authentication sounds a bit unconventional. Cannot you
> just talk about "attribute-based" authorization? That would be better
> aligned with SAML terminology.
Since this spec is being concocted in the context of the SIP working group, I
felt using SIP terminology was/es the way to go, see RFC4484. Though, we could
add an entry(ies) to the "2. terminology" section to help clarify items such as
this.
>> From the description in section 5 and figure 1, it is not always clear
> if you talk about an "authentication assertion" or an "attribute
> assertion"
I kept this deliberatively vague because section 5 is very high level. We could
perhaps add a sentence to the effect that a SAML assertion can be used to
assert attributes of a subject's authentication event and/or profile attributes.
> Figure 2, step 5: is it possible to have multiple attribute statements
> in the response? (for example, if possession of multiple attributes is
> required?)
yes. Also note that a given <saml:AttributeStatement> may assert any number of
attributes.
> Section 6.1.4.1.4: what does it mean if there is no attribute
> statement?
good point, the "MAY" in the first sentence arguably should be a "SHOULD".
However, some implementation & deployment might be conveying all the
information they need with other subelements of the SAML assertion, and so they
get all the semantics out of the assertion that they need without a
<saml:AttributeStatement>.
> is it an authentication assertion then?
No, not unless it explicitly contains an <saml:AuthnStatement>.
> Section 9.2: it would be nice to have some exaplanation there, without
> having to refer to a different spec/document.
ok, will think about what we can add there.
thanks for your review,
=JeffH
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
