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

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 10 Sep 2013 14:26:29 +0000

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.

---

From: Brian Campbell <[email-masked]>
Date: Tue, 10 Sep 2013 12:38:08 -0600

Regarding the second item about additional SAML related text - such
text already exists in the document in §5 [quoted and linked below].
It's unclear to me what else is being asked for here?

I'd like to request that some specific and concrete text be proposed,
if anyone believes the current wording is insufficient.

from tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-17#section-5
"5.  Interoperability Considerations

   Agreement between system entities regarding identifiers, keys, and
   endpoints is required in order to achieve interoperable deployments
   of this profile.  Specific items that require agreement are as
   follows: values for the issuer and audience identifiers, the location
   of the token endpoint, and the key used to apply and verify the
   digital signature over the assertion.  The exchange of such
   information is explicitly out of scope for this specification and
   typical deployment of it will be done alongside existing SAML Web SSO
   deployments that have already established a means of exchanging such
   information.  Metadata for the OASIS Security Assertion Markup
   Language (SAML) V2.0 [OASIS.saml-metadata-2.0-os] is one common
   method of exchanging SAML related information about system entities."

Thanks,
Brian

On Tue, Sep 10, 2013 at 8:26 AM, Tschofenig, Hannes (NSN - FI/Espoo)
<[email-masked]> wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Mike Jones <[email-masked]>
Date: Thu, 19 Sep 2013 14:48:39 +0000

I also think that the text is already there and these specs are ready to progress as-is.  If anyone disagrees, please let us know what text needs to be changed or added.

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Tuesday, September 10, 2013 11:38 AM
To: Tschofenig, Hannes (NSN - FI/Espoo)
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Next steps on the OAuth Assertion Drafts

Regarding the second item about additional SAML related text - such text already exists in the document in §5 [quoted and linked below].
It's unclear to me what else is being asked for here?

I'd like to request that some specific and concrete text be proposed, if anyone believes the current wording is insufficient.

Thanks,
Brian

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 19 Sep 2013 18:09:50 +0300

On 19.09.2013 17:48, Mike Jones wrote:
> I also think that the text is already there and these specs are ready
> to progress as-is.  If anyone disagrees, please let us know what text
> needs to be changed or added.

I dropped Barry a mail and I will have to carefully re-read the 
documents myself in preparation for the shepherd writeup.

Ciao
Hannes

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 28 Sep 2013 15:36:32 +0200

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.