I guess it's somewhat moot now because client assertions have been removed from the latest draft. However, I don't believe there anything saying that client assertions had to be bearer assertions. Nor would that really have been appropriate for the framework spec.
The same is true for extension/URI grant types (formerly known as assertion grant types). There is nothing in the core OAuth framework spec saying that it is, or has to be, a bearer assertion. The SAML Bearer Assertion Grant Type Profile is an extension spec that constrains/defines the specific use of bearer SAML assertion. To me and some others, that seemed like a useful enough use-case to write an I-D for, however, the main OAuth spec allows for other extensions. A holder of key SAML Assertion, for example, might be profiled as a grant type. Or something completely non SAML based. On Thu, Jan 20, 2011 at 10:11 PM, Francisco Corella <[email protected]>wrote: > Brian, > > Thank you for pointing me to the SAML Bearer Assertion Grant Type Profile. > I understand now. Maybe the spec would be clearer if it said that the > client assertion is a bearer assertion. > > Francisco > > --- On *Thu, 1/20/11, Brian Campbell <[email protected]>* wrote: > > > From: Brian Campbell <[email protected]> > Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials > and OAuth2 HTTP Authentication Scheme > To: [email protected] > Cc: "Eran Hammer-Lahav" <[email protected]>, "Mike Jones" < > [email protected]>, "[email protected]" <[email protected]>, "Karen P. > Lewison" <[email protected]> > Date: Thursday, January 20, 2011, 10:39 PM > > > Francisco, > > While a proper profiling of subject confirmation is generally needed for a > secure/interoperable SAML exchange, it's worth noting that assertions as > used in OAuth (client assertions or URI/assertion grant types) are not > necessarily SAML assertions. The term assertion is used more generally. To > be honest, I think token might have been be a less confusing term to use in > place of assertion in the framework spec. But token is widely used in other > contexts thought out the framework spec too. So I dunno, maybe that would > be even more confusing. > > If you are interested/knowledgeable about SAML subject confirmation, please > feel free to review and comment on the SAML Bearer Assertion Grant Type > Profile: http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-00 :) > > -Brian > > On Tue, Jan 18, 2011 at 1:26 PM, Francisco Corella > <[email protected]<http://mc/[email protected]> > > wrote: > > Mike, > > As assertion use is described in the spec, a client assertion does not > provide any security whatsoever. How do you handle subject confirmation in > your implementation? (See section 2.4.1.1 of the SAML > specification<http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf>.) > In other words, how does the authorization server know that the client > sending the assertion is actually the subject of the assertion? > > Francisco > > --- On *Tue, 1/18/11, Mike Jones > <[email protected]<http://mc/[email protected]> > >* wrote: > > > From: Mike Jones > <[email protected]<http://mc/[email protected]> > > > Subject: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and > OAuth2 HTTP Authentication Scheme > To: "Eran Hammer-Lahav" > <[email protected]<http://mc/[email protected]> > > > Cc: "[email protected] <http://mc/[email protected]>" > <[email protected]<http://mc/[email protected]> > > > Date: Tuesday, January 18, 2011, 5:35 PM > > > Having spoken to a number of people implementing the spec here, I’ve > encountered strong objections to removing Client Assertion Credentials and > the OAuth2 HTTP Authentication Scheme. It’s also not clear to me why we > would make substantial breaking changes to the specification when it is > essentially ready for approval. I’ve summarized the reasons I believe we > should keep these two features below. > > *Client Assertion Credentials:* Many of the scenarios we care about > require this capability. They were key motivators for the Assertion Profile > in WRAP (see § 5.2), have been part of OAuth 2 for quite a while, and we > have running code that requires this support. For example, the Azure Access > Control Service is a cloud Authorization server that supports several > protocols, including parts of OAuth 2.0 draft 10 (autonomous and web server > profiles). We are happy to update our implementation to subsequent drafts & > agree that the spec leaves a lot of ambiguity. > > In our implementation of the autonomous and web server profiles, ACS allows > clients to authenticate using a signed assertion as well as with a > username/password. The username/pwd option is for clients that don’t mind > sending credentials over the wire, while the signed assertion mechanism is > for clients that are more reticent to send raw credentials and for scenarios > where it isn’t possible. To illustrate an example where username/pwd isn’t > viable, consider the case of a client that needs to use an enterprise > identity to gain access to a cloud service. In many cases, corporate policy > demands that a client use an identity managed by the organization. This > means that the client should obtain an assertion from an enterprise identity > provider (Active Directory, Tivoli, etc.) and use that assertion to obtain > an access token which grants access to various web service APIs. Many of our > key MSFT customers and internal partner teams rely on this mechanism and > reverting exclusively to username/pwd isn’t an option for us. > > > > *'OAuth2' HTTP Authentication Scheme:* Simply put, dropping this seems > like a huge step away from interoperability. As one data point, Microsoft > implements this in our WIF OAuth2 protected resource code. All up, clients > need a way to authenticate to the protected resource. Also, existing WRAP > implementations need this functionality to migrate to OAuth2. For all > these reasons, we support retaining this functionality in OAuth2. > > > > Thanks, > > -- Mike > > > > -----Inline Attachment Follows----- > > _______________________________________________ > OAuth mailing list > [email protected] <http://mc/[email protected]> > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > [email protected] <http://mc/[email protected]> > https://www.ietf.org/mailman/listinfo/oauth > > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
