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
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
