Re: [OAUTH-WG] Assertion Draft: Text about Interoperability -- Today

[Brian Campbell <[e-mail]>]

I apologize for not participating in much of the discussion around this -
I've been otherwise occupied this week with a myriad of other priorities at
work.

I would, however, like to voice my support in favor of the version of the
text that Mike proposed.


On Fri, Jan 18, 2013 at 3:59 PM, Mike Jones <[e-mail]>wrote:

> To make the proposed changes concrete, I've made them in a proposed draft
> 10 (attached).  This contains no normative changes from draft 9.  People
> should look at Section 1.1 (Interoperability Considerations) and review the
> new text there.  The only other change was renaming "Principal" to
> "Subject" to align terminology with the SAML and JWT specs, as discussed on
> the list.
>
> I will wait for OK from one of the chairs or Stephen before checking this
> in.
>
>                                 -- Mike
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Mike Jones
> Sent: Friday, January 18, 2013 2:31 PM
> To: Stephen Farrell; Tschofenig, Hannes (NSN - FI/Espoo)
> Cc: [e-mail]
> Subject: Re: [OAUTH-WG] Assertion Draft: Text about Interoperability --
> Today
>
> I can't agree with proceeding with Hannes' rewrite of the interoperability
> text, as editorially, it reads like it is apologizing for a defect in the
> specification, whereas it is an intentional feature of the specification
> that the syntax and verification rules of some fields is intentionally left
> open for profiles to specify (even while the semantics of them is defined
> by the Assertions spec).  I propose that instead, we go with the revised
> version at the end of this message, which I believe incorporates Hannes'
> ideas while keeping the editorial tone positive.
>
> Second, I believe that we should proceed with the non-normative
> terminology change of "Principal" to "Subject", which was proposed in
> http://www.ietf.org/mail-archive/web/oauth/current/msg10530.html and
> supported by Justin and Torsten, with no one opposed.  This should go into
> the version being discussed on the telechat (as well as the
> interoperability text).
>
> Finally, I believe that it would be beneficial to all to have the
> Assertions and SAML Profile specs be discussed on the same telechat, as
> both are useful for understanding the other.  Frankly, I think they should
> go to the IETF Editor together as "related specifications", with the goal
> being consecutively numbered RFCs referencing one another.  Is there any
> reason we can't schedule both for the February 7th telechat?  (I don't
> actually understand how they failed to proceed in lock-step in the first
> place.  Chairs - any insights?)
>
> ====
>
> Interoperability Considerations
>
> This specification defines a framework for using assertions with OAuth
> 2.0. However, as an abstract framework in which the data formats used for
> representing many values are not defined, on its own, this specification is
> not sufficient to produce interoperable implementations.
>
> Two other specifications that profile this framework for specific
> assertion have been developed:  one ([I-D.ietf-oauth-saml2-bearer]) uses
> SAML 2.0-based assertions and the other ([I-D.ietf-oauth-jwt-bearer]) uses
> JSON Web Tokens (JWTs).  These two instantiations of this framework specify
> additional details about the assertion encoding and processing rules for
> using those kinds of assertions with OAuth 2.0.
>
> However, even when profiled for specific assertion types, additional
> profiling for specific use cases will be required to achieve full
> interoperability.  Deployments for particular trust frameworks, circles of
> trust, or other uses cases will need to agree among the participants on the
> kinds of values to be used for some abstract fields defined by this
> specification.  For example the values of Issuer, Subject, and Audience
> fields might be URLs, URIs, fully qualified domain names, OAuth client IDs,
> IP addresses, or other values, depending upon the requirements of the
> particular use case.  The verification rules for some values will also be
> use case specific.
>
> This framework was designed with the clear expectation that additional
> specifications will define prescriptive profiles and extensions necessary
> to achieve full web-scale interoperability for particular use cases.
>
> ====
>
>                                 Thanks all,
>                                 -- Mike
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Stephen Farrell
> Sent: Friday, January 18, 2013 9:47 AM
> To: Tschofenig, Hannes (NSN - FI/Espoo)
> Cc: [e-mail]
> Subject: Re: [OAUTH-WG] Assertion Draft: Text about Interoperability --
> Today
>
>
> Hiya,
>
> So I'll take the lack of further discussion about this an meaning that the
> wg want this to shoot ahead. I'll put this in as an RFC editor note for the
> draft.
>
> Cheers,
> S.
>
> On 01/18/2013 12:04 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
> > Hi all,
> >
> > As you have seen on the list (see
> > http://www.ietf.org/mail-archive/web/oauth/current/msg10526.html) I
> > had a chat with Mike about how to address my comment for the assertion
> > draft and Mike kindly provided his text proposal (see
> > http://www.ietf.org/mail-archive/web/oauth/current/msg10529.html). I
> > have used his text as input and extended it a bit. Here is the updated
> > text.
> >
> > ----
> >
> > Operational Considerations and Interoperability Expectations
> >
> > This specification defines a framework for using assertions with OAuth
> > 2.0. However, as an abstract framework on its own, this specification
> > is not sufficient to produce interoperable implementations. Two other
> > specifications that instantiate this framework have been developed,
> > one uses SAML 2.0-based assertions and is described in
> > [I-D.ietf-oauth-saml2-bearer] and the second builds on JSON Web Tokens
> > (JWTs) and can be found in [I-D.ietf-oauth-jwt-bearer]. These two
> > instantiations provide additional details about the assertion encoding
> > and processing rules for those interested to implement and deploy
> > assertions with OAuth 2.0.
> >
> > However, even with these instance documents an interoperable
> > implementation is not possible since for a specific deployment
> > environment (within a trust framework or circle of trust, as it is
> > sometimes called) agreements about acceptable values for various
> > fields in the specification have to be agreed upon. For example, the
> > audience field needs to be populated by the entity that generates the
> > assertion with a specific value and that value may hold identifiers of
> > different types (for example, a URL, an IP address, an FQDN) and the
> > entity receiving and verifying the assertion must compare the value in
> > the audience field with other information it may obtain from the
> > request and/or with locally available information. Since the abstract
> > framework nor the instance documents provide sufficient information
> > about the syntax, the semantic and the comparison operation of the
> > audience field additional profiling in further specifications is
> > needed for an interoperable implementation. This additional profiling
> > is not only needed for the audience field but also for other fields as
> well.
> >
> > This framework was designed with the expectation that additional
> > specifications will fill this gap for deployment-specific environments.
> >
> > ----
> >
> > You have the choice:
> >
> > 1. take this as-is if you want the assertion draft
> > (draft-ietf-oauth-assertions ) on the Jan 24 IESG telechat. There is
> > no normative text in the writeup; it is rather a clarification.
> >
> > 2. discuss it if need be, and draft-ietf-oauth-assertions will be on
> > the Feb 7
> >    telechat (if the discussion is done by Feb 1)
> >
> > 1 or 2 needs to be chosen today.
> >
> >
> > Ciao
> > Hannes
> >
> > PS: FYI - draft-ietf-oauth-saml2-bearer and
> > draft-ietf-oauth-jwt-bearer are not yet on the telechat agenda.
> >
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> >
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>