Hi Brian,
thank you for taking the effort to write this I-D.
I have the following remarks:
Why do you prescribe to include the token endpoint URL into the
SubjectConfirmationData and similar data also in the
AudienceRestriction? I would expect such data in the AudienceRestriction
only.
Why do you prohibit NotBefore-Attributes?
What the reason for that statement? "If the assertion was issued with
the intention that the client act autonomously on behalf of the subject,
an <AuthnStatement> SHOULD NOT be included." Do you expect the OAuth
authorization server to authenticate the client anyway?
Your I-D states:
"The authorization server MUST ensure that bearer assertions are
not replayed, by maintaining the set of used ID values for the
length of time for which the assertion would be considered valid
based on the NotOnOrAfter attribute in the
<SubjectConfirmationData>."
Why do you want to force a one-time usage for SAML assertions? This is
to restrictive, in my opinion. Any issuing authority could enforce such
a policy by using the "OneTimeUse" element.
2.3. Error Response: I would suggest to return a 401 status code for
invalid assertions since I see them as invalid credentials.
regards,
Torsten.
Am 15.07.2010 22:50, schrieb Brian Campbell:
I'm gong to join the growing list of people attaching a potential I-D
to an email due to he cut off time for the I-D submissions. Attached
is a draft that aims to tightly define the particular format of a SAML
2.0 bearer assertion in requesting an access token using the assertion
grant_type. I've been working with Chuck at Salesforce.com on this
and the primary goal is to have some documentation or specification
that is sufficient to facilitate interoperability between
independently developed implementations or products. This, of
course, wouldn't preclude using SAML in other ways - it would only
provide one concrete definition to implement against.
I intend to submit this as an I-D when the submission process reopens.
Any feedback from this group would be appreciated as well as
thoughts about this eventually becoming a working group draft.
Thanks,
Brian Campbell
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
