In thinking about this I'm coming around to the viewpoint that a single
additional predefined spot is sufficient. If the app developer wants to
include addtional data there (iun the specified format) that's fine. If what
they want to do is include a signature of other payload that's fine too.
Only allowing (implied or not) app data is needlessly narrow in scope.
Extending MAC to include claims or session information is a perfectly valid
thing to do. It improves scalability and reduces the need to look up artifact
data.
Note: I'd like to share more on this, but I'm prioritizing
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol Working Group of
the IETF.
Title : SAML 2.0 Bearer Assertion Profiles for OAuth 2.0
Author(s) : Chuck Mortimore
This 'nice' version of this is at
http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-05
The draft has been reworked significantly to become a profile of
http://tools.ietf.org/html/draft-ietf-oauth-assertions-00 and cover
both assertions as access grants as well as assertions as client
One of the changes I made in
http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-05 was to
drop the parameter registration request for the assertion parameter
because the parameter is now defined in
http://tools.ietf.org/html/draft-ietf-oauth-assertions however that
document doesn't currently
