Re: [OAUTH-WG] Next steps on the OAuth Assertion Drafts

[Torsten Lodderstedt <[e-mail]>]

Hi all,

here are my comments:

--- Assertion Draft ---

section 4.1.

"Authentication of the client is optional, as described in Section
    3.2.1 of OAuth 2.0 [RFC6749] and consequently, the "client_id" is
    only needed when a form of client authentication that relies on the
    parameter is used."

I'm a bit confused about this statement because RFC6749, Section 3.2.1. 
states:
"Confidential clients or other clients issued client credentials MUST
    authenticate with the authorization server as described in
    Section 2.3 when making requests to the token endpoint."

The client_id is optional but recommended for public clients, only. Same 
text can be found in SAML/section 2.1 and JWT/section 2.1

section 5.1.

"the Issuer should identify the STS in a manner recognized by the 
Authorization Server."

Shouldn't the "should" be normative language? I would even prefer MUST 
instead of should.

"Issuer values SHOULD be compared using the Simple String Comparison" - 
better MUST?

"When using assertions for client authentication, the Subject
          MUST identify the client to the authorization server, typically
          by using the value of the "client_id" of the OAuth client."

Why not just "For client authentication, the subject MUST be the 
"client_id" of the OAuth client" as in the JWT Bearer and SAML assertion 
drafts?

Audience - "The URL of the Token Endpoint, as defined
       in Section 3.2 of OAuth 2.0 [RFC6749], can be used to indicate
       that the authorization server as a valid intended audience of the
       assertion."

Who uses this approach? We don't use the concrete URL of the tokens 
endpoint but the AS's base URL. I would prefer to have _a_ single, 
mandated way of identifying the AS instead of a recommendation in order 
to facilitate interop.

section 6.2

Please replace "Client Credentials flow" by "Client Credentials _Grant_"

PLEASE NOTE: most comments on the assertion draft hold for JWT and SAML 
as well because a lot of text is duplicated/shared among these drafts.

--- JWT bearer token ---

section 4

the example request is missing any client identifier/credentials, please 
add BASIC header or client_id

GENERAL NOTE: HTML links referencing to RFC 6749 are generally linked to 
the respective drafts itself

regards,
Torsten.

Am 10.09.2013 16:26, schrieb Tschofenig, Hannes (NSN - FI/Espoo):
> Hi all,
>
> I am trying to wrap up the assertion documents and I took a look at the meeting minutes from the Berlin IETF meeting and the actions are as follows:
>
> ** John & Torsten: Please post your document review to the list.
>
> ** Authors of draft-ietf-oauth-saml2-bearer: Please provide the additional SAML related text (as discussed during the meeting) and submit an updated document.
>
> Ciao
> Hannes
>
> ------- copy from the minutes --------
>
> * Assertions (BC)
>   https://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/
>   https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/
>   https://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/
>
>      - WGLC ends by 8/8
>      - BL on WGLC comments: talked to MJ about how to achieve interop.
>      - BL: describe how you could combine specifications to make at least one interoperable specification
>      - MJ: profiles exists for both SAML and OpenIDC. those are not IETF specifications though
>      - BL: ok to point to external doc from either of the I-Ds in question
>      - MJ: very achievable
>      - BL: all should go to the IESG at the same time to establish context
>      - PHO: is this for the IESG benefit or for future developers
>      - BL: the latter
>      - PHO: talk to Heather Flanagan or the IANA - they have talked about having long-term access to external documents
>      - BL: ok will consider that - or we can copy text into WG wiki
>      - BC: interop does not require external profiles actually
>      - TL: same experience at DT with the JSON-based assertion format - no addl profiles are needed
>      - MJ: a SAML deployment needs agreement on certain SAML-specific conventions - this is what BL is referring to
>      - BC: right
>      - TN: so just refer to the SAML specs
>      - BL: maybe enough
>      - JB and TL volunteered to make a review.
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth