[OAUTH-WG] Re: [IANA #1372073] expert review for draft-ietf-oauth-resource-metadata (well-known-uris)
Hi David, That looks fine to me. Cheers, > On 14 Aug 2024, at 7:14 AM, David Dong via RT > wrote: > > Dear Mark (cc: oauth WG), > > As the designated expert for the Well-Known URIs registry, can you review the > proposed registration in draft-ietf-oauth-resource-metadata-08 for us? Please > see: > > https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-metadata/ > > The due date is August 27. > > If this is OK, when the IESG approves the document for publication, we'll > make the registration at: > > https://www.iana.org/assignments/well-known-uris/ > > With thanks, > > David Dong > IANA Services Sr. Specialist -- Mark Nottingham https://www.mnot.net/ ___ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
Re: [OAUTH-WG] Httpdir telechat review of draft-ietf-oauth-step-up-authn-challenge-13
___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Httpdir telechat review of draft-ietf-oauth-step-up-authn-challenge-13
Reviewer: Mark Nottingham Review result: Not Ready # HTTPDIR review of drat-ietf-oauth-step-up-authn-challenge-13 I am an assigned HTTP directorate reviewer for draft-ietf-masque-connect-ip. These comments were written primarily for the benefit of the ART Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the HTTP Directorate, see https://datatracker.ietf.org/group/intdir/about/. I've entered a 'not ready' position because of the first issue below; the remaining are relatively easy to address. ## Comments ### Global HTTP Authentication Parameters This draft seems to modify the HTTP authentication mechanism globally, regardless of the scheme in use. For example: "This specification introduces a new error code value for the error parameter of [RFC6750] or authentication schemes, such as [I-D.ietf-oauth-dpop], which use the error parameter" [...] "Furthermore, this specification defines additional WWW-Authenticate auth-param values to convey the authentication requirements back to the client." [...] "A client receiving an authorization error from the resource server carrying the error code insufficient_user_authentication SHOULD parse the WWW-Authenticate header for acr_values and max_age and use them, if present, in constructing an authorization request" If that is the intent, you need to update RFC9110 (which is likely to be contentious); otherwise, you need to scope it in such a way that authentication schemes 'opt into' their use. ### Header Definition "This document also introduces acr_values and max_age parameters for the WWW-Authenticate response header defined by [RFC6750]" RFC6750 does not define WWW-Authenticate; RFC9110 does. ## Nits I found the terminology in this draft confused, and confusing. E.g., * Use of the term 'resource server' throughout is very jarring -- on the Web, it's just a 'resource'. The 'server' is responsible for the resource; if you mean the server, say 'server'; if you mean the resource, say 'resource'. Don't combine them. * Likewise, 'resource request' is redundant; every request is for a resource. Just say 'request'. * Similarly, the diagram on page 4 shows a 'resource server' returning a 'protected resource'. Resources are never transferred over the network; they send representations in responses -- one of those terms should be used. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [IANA #1264432] expert review for draft-ietf-oauth-dpop (http-fields)
I thought we already had; if not, approved. Cheers, > On 9 Mar 2023, at 12:32 pm, Mike Jones > wrote: > > Hi Mark, > We’ve published > https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-14.html, which > incorporates the PR. Could you please approve IANA registration of the HTTP > fields on that basis? > Thanks again for your help with the draft. > -- Mike > From: OAuth On Behalf Of Mike Jones > Sent: Tuesday, March 7, 2023 8:58 PM > To: Mark Nottingham > Cc: Roy Fielding ; Amanda Baber via RT > ; oauth@ietf.org > Subject: Re: [OAUTH-WG] [IANA #1264432] expert review for > draft-ietf-oauth-dpop (http-fields) > Thanks - will do. > From: Mark Nottingham > Sent: Tuesday, March 7, 2023 7:55:29 PM > To: Mike Jones > Cc: Brian Campbell ; Amanda Baber via RT > ; oauth@ietf.org ; Roy > Fielding > Subject: Re: [OAUTH-WG] [IANA #1264432] expert review for > draft-ietf-oauth-dpop (http-fields) > Hi Mike, > > Thanks. I left a comment on the PR, suggesting two small tweaks. > > Cheers, > > > > On 8 Mar 2023, at 2:33 pm, Mike Jones > > wrote: > > > > Hi Mark, > > > > I've created the pull request > > https://github.com/danielfett/draft-dpop/pull/180 to incorporate your > > suggestions. Please also see some additional replies below, which are > > prefixed by "Mike>". > > > > Please let us know if you'd like to see any changes to the PR before we > > merge it and publish an updated draft incorporating your suggestions. > > > > Thanks, > > -- Mike > > > > -Original Message- > > From: Mike Jones > > Sent: Monday, January 23, 2023 11:42 PM > > To: 'Mark Nottingham' ; Brian Campbell > > > > Cc: Amanda Baber via RT ; > > oauth@ietf.org; Roy Fielding > > Subject: RE: [OAUTH-WG] [IANA #1264432] expert review for > > draft-ietf-oauth-dpop (http-fields) > > > > Hi Mark, > > > > Like Brian, I appreciate your detailed review. My thoughts on the review > > points are interleaved with the discussion text below. > > > >> Keep in mind that HTTP header fields are basically sets of constrained > >> octets with weird combination rules; if you don't use SF, you should be > >> specifying (for example) what happens when two header values (and/or > >> fields) are present (as per below). SF does a lot of the legwork here, > >> even if from a type system standpoint it's not a perfect fit. > > > > I agree that we should specify these things - probably using language > > parallel to that in the SF draft, where appropriate. I also share your > > assessment that, unfortunately, the SF type system is not an ideal fit for > > the DPoP headers. > > > > Mike> > > https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-13.html#name-checking-dpop-proofs > > does include the validation check "there is not more than one DPoP HTTP > > request header field". In the PR, I also explicitly added that the there > > is a single field value. > > > >> That said, personally I'd deconstruct the JWT and convey it as separate > >> binary values, so that if binary structured headers ever does catch on, it > >> can get the perf/compactness advantages of that. > > > > Deconstructing the JWT would entail defining a new JWT serialization > > (representation). Currently there is exactly one JWT serialization and > > this specification uses it. I suspect developers would like us to keep it > > that way. > > > > Only one of the fields of a signed JWT is actually binary (the signature); > > the header and payload are JSON. All are encoded using the base64 URL-safe > > character set (letters, numbers, -, and _ with no trailing =s) for safe > > transmission with encoded fields separated by the also URL-safe character > > period. Furthermore, the signature is computed over the base64url-encoded > > values of the first two fields with a period between them. The base64url > > encoding and concatenation is integral to the computation of the signature. > > Any different serialization would still have to perform these computations. > > > > (Note also that some JWTs have three base64url-encoded fields separated by > > period characters and some have five, depending upon whether they are > > signed (three) or encrypted (five); deconstructing a value with a variable > > number of non-independent fields seems like significant unnecessary &g
Re: [OAUTH-WG] [IANA #1264432] expert review for draft-ietf-oauth-dpop (http-fields)
Hi Mike, Thanks. I left a comment on the PR, suggesting two small tweaks. Cheers, > On 8 Mar 2023, at 2:33 pm, Mike Jones > wrote: > > Hi Mark, > > I've created the pull request > https://github.com/danielfett/draft-dpop/pull/180 to incorporate your > suggestions. Please also see some additional replies below, which are > prefixed by "Mike>". > > Please let us know if you'd like to see any changes to the PR before we merge > it and publish an updated draft incorporating your suggestions. > > Thanks, > -- Mike > > -Original Message- > From: Mike Jones > Sent: Monday, January 23, 2023 11:42 PM > To: 'Mark Nottingham' ; Brian Campbell > > Cc: Amanda Baber via RT ; > oauth@ietf.org; Roy Fielding > Subject: RE: [OAUTH-WG] [IANA #1264432] expert review for > draft-ietf-oauth-dpop (http-fields) > > Hi Mark, > > Like Brian, I appreciate your detailed review. My thoughts on the review > points are interleaved with the discussion text below. > >> Keep in mind that HTTP header fields are basically sets of constrained >> octets with weird combination rules; if you don't use SF, you should be >> specifying (for example) what happens when two header values (and/or fields) >> are present (as per below). SF does a lot of the legwork here, even if from >> a type system standpoint it's not a perfect fit. > > I agree that we should specify these things - probably using language > parallel to that in the SF draft, where appropriate. I also share your > assessment that, unfortunately, the SF type system is not an ideal fit for > the DPoP headers. > > Mike> > https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-13.html#name-checking-dpop-proofs > does include the validation check "there is not more than one DPoP HTTP > request header field". In the PR, I also explicitly added that the there is > a single field value. > >> That said, personally I'd deconstruct the JWT and convey it as separate >> binary values, so that if binary structured headers ever does catch on, it >> can get the perf/compactness advantages of that. > > Deconstructing the JWT would entail defining a new JWT serialization > (representation). Currently there is exactly one JWT serialization and this > specification uses it. I suspect developers would like us to keep it that > way. > > Only one of the fields of a signed JWT is actually binary (the signature); > the header and payload are JSON. All are encoded using the base64 URL-safe > character set (letters, numbers, -, and _ with no trailing =s) for safe > transmission with encoded fields separated by the also URL-safe character > period. Furthermore, the signature is computed over the base64url-encoded > values of the first two fields with a period between them. The base64url > encoding and concatenation is integral to the computation of the signature. > Any different serialization would still have to perform these computations. > > (Note also that some JWTs have three base64url-encoded fields separated by > period characters and some have five, depending upon whether they are signed > (three) or encrypted (five); deconstructing a value with a variable number of > non-independent fields seems like significant unnecessary complexity.) > >>> ABNF syntax for the nonce value is provided at >>> https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-12.html#section-8-9 >>> along with the description of its use in the DPoP exchange. > >> I see. It'd be better if it were explicitly called out as the syntax for the >> field (ideally with a section title that makes this clear), rather than >> making the reader do that work. > > Mike> The nonce syntax ABNF now has its own section title in the PR. > > I'm fine with us making the editorial improvement that you suggest. > >>> I believe that the SF String type would accommodate the content we intended >>> to allow servers to use for the nonce (it's basically a server chosen value >>> that the client treats as opaque and sends back in subsequent DPoP proof >>> JWTs). However, that would be a breaking change, which shouldn't be >>> undertaken lightly. > >> Right. It really depends on how advanced deployment of this is; if there's >> only modest production use, it may still be reasonable to make such a change >> (especially keeping in mind that people who adopt drafts need to bear the >> consequences of doing so). > > I'm with Brian here. I don't believe that the cost/benefit tradeoff of the > breaking
Re: [OAUTH-WG] [IANA #1264432] expert review for draft-ietf-oauth-dpop (http-fields)
I'll commit to us answering them in the >> next draft. >> >>>>> - The long line-wrapped example in Section 4.1 would benefit from >>>>> RFC8792 encoding. In HTTP, a line-wrapped field like the one shown >>>>> has whitespace inserted between each line, which is problematic >>>>> here. >>> >>>> This is a bit of a stylistic preference thing. That example and >>>> others in the draft are intentionally similar (with a note about >>>> line breaks and extra space being for display purposes) to closely >>>> related and referenced documents like RFC7515, RFC7519, and RFC6749. >>>> The examples from these RFCs seem to have worked well for >>>> readers/implementers in practice, and so we'd prefer to keep the >>>> formatting conventions in this draft the same as in those. >>> >>> Consistency between documents that specify HTTP protocol elements is >>> important, so I'd ask you to reconsider; while the community that has >>> been developing and implementing the specification may already be >>> familiar with it, aligning with other documents makes it easier for a >>> broader audience. See, for example, the Signatures specification: >>> https://httpwg.org/http-extensions/draft-ietf-httpbis-message- >>> signatures.html#name-request-response-signature- >> >> I'm fine with us making this editorial change to the examples, since >> you feel that this would help some readers of the specification. >> >> In closing, I'll say that I appreciate that the SF spec has done heavy >> lifting that we would do well to take advantage of. I appreciate you >> bringing it to our attention. That said, since SF's type system does >> not cleanly map to some of the DPoP fields, and since the use of SF is >> optional, I personally believe that the best route for us to take >> advantage of SF is to study it and ensure that the questions that SF >> answers for the field types that it defines are also answered for the >> fields defined by the DPoP draft. >> >> Best wishes, >> -- Mike >> >> -Original Message- >> From: OAuth On Behalf Of Mark Nottingham >> Sent: Sunday, January 22, 2023 7:13 PM >> To: Brian Campbell >> Cc: Amanda Baber via RT ; >> oauth@ietf.org; Roy Fielding >> Subject: Re: [OAUTH-WG] [IANA #1264432] expert review for draft-ietf- >> oauth-dpop (http-fields) >> >> Hi Brian, >> >>> On 21 Jan 2023, at 5:46 am, Brian Campbell >>> wrote: >>> >>> >>> Hi Mark, >>> >>> Thanks for the review and feedback. I am aware of HTTP Structured >>> Fields and certainly see value in it - even using it in some other >>> work in which I'm involved. However, I'm unsure of its fit or utility >>> for this draft. With that said, I've tried to reply more specifically >>> to your comments inline below. >>> >>> >>> On Wed, Jan 18, 2023 at 3:32 PM Mark Nottingham >>> wrote: >>> A few things caught my eye in this document: >>> >>> - Section 4.1 defines the DPoP header field as a JWT, which (as I >>> understand it) is a base64-encoded string. If that's the case, I'd >>> recommend making it a Structured Field Item (see RFC8941 s 3.3) with >>> a fixed type of Byte Sequence (s 3.3.5). That will require changing >>> the syntax to add a prefix and suffix of ":". >>> >>> As Justin pointed out, a JWT is three Base64url encoded segments >>> delimited by the `.` period character, which means it can't be a SF >>> Byte Sequence. As DW pointed out, a JWT just happens to always start >>> with a letter because the first segment is always encoded JSON, so >>> will always start with 'ey'. So the DPoP header field value does just >>> happen to fit the SF Token syntax, But the SF Token syntax does very >>> little regarding the validity of the JWT. >> >> Keep in mind that HTTP header fields are basically sets of constrained >> octets with weird combination rules; if you don't use SF, you should >> be specifying (for example) what happens when two header values >> (and/or fields) are present (as per below). SF does a lot of the >> legwork here, even if from a type system standpoint it's not a perfect >> fit. >> >> That said, personally I'd deconstruct the JWT and convey it as >> separate binary values, so that if binary structured headers ever does >
Re: [OAUTH-WG] [IANA #1264432] expert review for draft-ietf-oauth-dpop (http-fields)
Hi Brian, > On 21 Jan 2023, at 5:46 am, Brian Campbell > wrote: > > > Hi Mark, > > Thanks for the review and feedback. I am aware of HTTP Structured Fields and > certainly see value in it - even using it in some other work in which I'm > involved. However, I'm unsure of its fit or utility for this draft. With that > said, I've tried to reply more specifically to your comments inline below. > > > On Wed, Jan 18, 2023 at 3:32 PM Mark Nottingham > wrote: > A few things caught my eye in this document: > > - Section 4.1 defines the DPoP header field as a JWT, which (as I understand > it) is a base64-encoded string. If that's the case, I'd recommend making it a > Structured Field Item (see RFC8941 s 3.3) with a fixed type of Byte Sequence > (s 3.3.5). That will require changing the syntax to add a prefix and suffix > of ":". > > As Justin pointed out, a JWT is three Base64url encoded segments delimited by > the `.` period character, which means it can't be a SF Byte Sequence. As DW > pointed out, a JWT just happens to always start with a letter because the > first segment is always encoded JSON, so will always start with 'ey'. So the > DPoP header field value does just happen to fit the SF Token syntax, But the > SF Token syntax does very little regarding the validity of the JWT. Keep in mind that HTTP header fields are basically sets of constrained octets with weird combination rules; if you don't use SF, you should be specifying (for example) what happens when two header values (and/or fields) are present (as per below). SF does a lot of the legwork here, even if from a type system standpoint it's not a perfect fit. That said, personally I'd deconstruct the JWT and convey it as separate binary values, so that if binary structured headers ever does catch on, it can get the perf/compactness advantages of that. > - The DPoP-Nonce header field's syntax isn't obviously specified. It should > be. I'd suggest a Structured Field Item with a fixed type of String (RFC 8941 > s 3.3.3), which would surrounding the value with quotes. > > ABNF syntax for the nonce value is provided at > https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-12.html#section-8-9 > along with the description of its use in the DPoP exchange. I see. It'd be better if it were explicitly called out as the syntax for the field (ideally with a section title that makes this clear), rather than making the reader do that work. > I believe that the SF String type would accommodate the content we intended > to allow servers to use for the nonce (it's basically a server chosen value > that the client treats as opaque and sends back in subsequent DPoP proof > JWTs). However, that would be a breaking change, which shouldn't be > undertaken lightly. Right. It really depends on how advanced deployment of this is; if there's only modest production use, it may still be reasonable to make such a change (especially keeping in mind that people who adopt drafts need to bear the consequences of doing so). > - Neither header has interoperable parsing or serialisation specified; > divergent error handling may cause interoperability problems. Adopting > Structured Fields would address this. > > Both are composed of a narrow set of printable ASCII with parsing, > validation, usage, and error handling specified at the application layer. I'm > not going to claim that it's perfect by any means. But those interoperability > problems seem conjectural and it's not obvious that adopting Structured > Fields would add value in the context of this draft. To be concrete -- what should an implementation do when it receives two DPoP header fields, both with valid values? When it receives one with two comma-separated values? > - See RFC9110 s 16.3.2 for things that should be considered when defining new > HTTP fields. I suspect that the document needs to be more explicit about at > least some of these items. Adopting Structured Fields would address some (but > not all) of these questions. > > The authors (on-behalf-of and with the help of the WG) have endeavored to > touch on all the considerations needed to ensure interoperability of the > protocol overall as well as HTTP related (e.g. caching, applicability to > request/response, prohibiting multiple occurrences, scope of applicability). > However, the group clearly does not have your depth of HTTP expertise so may > well have missed something. If that's the case, it would be very helpful for > specifics to be raised. > > - See also > <https://httpwg.org/admin/editors/style-guide#header-and-trailer-fields> for > the preferred editoria
Re: [OAUTH-WG] [IANA #1264432] expert review for draft-ietf-oauth-dpop (http-fields)
> On 20 Jan 2023, at 3:18 am, Justin Richer wrote: > > A JWT cannot be sent as a Byte Sequence because it is not :just: Base64. > Specifically, a JWT in compact serialization (which is what’s intended here) > is encoded as three sets of Base64url separated by periods “.”, which are > outside the base64URL alphabet. If anything, this fits the “token68” rule, > which I :think: means that it could be defined as sf-token here, to make it a > fully structured field, but I’m not entirely sure. Ah, interesting. Token has a constraint on the first character -- it must be a letter. Is that always the case for a JWT? If not, two other options: - It could be conveyed as a String (surround with ") - The three components could be decomposed and each conveyed separately Cheers, -- Mark Nottingham https://www.mnot.net/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [IANA #1264432] expert review for draft-ietf-oauth-dpop (http-fields)
A few things caught my eye in this document: - Section 4.1 defines the DPoP header field as a JWT, which (as I understand it) is a base64-encoded string. If that's the case, I'd recommend making it a Structured Field Item (see RFC8941 s 3.3) with a fixed type of Byte Sequence (s 3.3.5). That will require changing the syntax to add a prefix and suffix of ":". - The DPoP-Nonce header field's syntax isn't obviously specified. It should be. I'd suggest a Structured Field Item with a fixed type of String (RFC 8941 s 3.3.3), which would surrounding the value with quotes. - Neither header has interoperable parsing or serialisation specified; divergent error handling may cause interoperability problems. Adopting Structured Fields would address this. - See RFC9110 s 16.3.2 for things that should be considered when defining new HTTP fields. I suspect that the document needs to be more explicit about at least some of these items. Adopting Structured Fields would address some (but not all) of these questions. - See also <https://httpwg.org/admin/editors/style-guide#header-and-trailer-fields> for the preferred editorial style when defining new HTTP fields. - The long line-wrapped example in Section 4.1 would benefit from RFC8792 encoding. In HTTP, a line-wrapped field like the one shown has whitespace inserted between each line, which is problematic here. Cheers, > On 19 Jan 2023, at 5:30 am, David Dong via RT > wrote: > > Dear Mark Nottingham and Roy Fielding (cc: oauth WG), > > As the designated experts for the http-fields registry, can you review the > proposed registration in draft-ietf-oauth-dpop for us? Please see: > > https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/ > > The due date is February 1st, 2023. > > If this is OK, when the IESG approves the document for publication, we'll > make the registration at > > https://www.iana.org/assignments/http-fields/http-fields.xhtml > > We'll wait for both reviewers to respond unless you tell us otherwise. > > With thanks, > > David Dong > IANA Services Specialist -- Mark Nottingham https://www.mnot.net/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] .well-known/jwks.json and constrained-voucher and RFC7517
Hi, Could you take me off the cc please? Thanks. Sent from my iPhone > On 13 Jul 2022, at 4:18 pm, Neil Madden wrote: > > >> On 12 Jul 2022, at 20:26, Michael Richardson wrote: >> >> >> EXEC-SUM: /.well-known/jwks.json seems in use, but not registered >> with IANA. I don't know if it's appropriate for my use. >> Seems to contain RFC7517 content. > > A limitation of the JWKSet format is that it provides no way to designate > which keys in the set are intended for what function. For example if I have > some keys I use for signing OIDC id tokens and another set of keys I use for > signing software updates, there is no way to distinguish them if they are all > in a single JWKSet (unless those functions use different algorithms). It is > therefore wise to have distinct JWKSets published on distinct URIs for > distinct functionality. A single well-known jwks.json is putting all your > keys in one basket and will inevitably (IMO) lead to problems, maybe even > security issues. > > (I have seen some software use the “kid” to indicate purpose, but if you > support key rotation then you’ll end up with duplicate “kid” values, which > causes issues in some client software). > > — Neil ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Building Real Internet Platforms
Just to +1 and add my bit: in my mind one of the fundamental flaws of the Web is that it is basically a platform construction toolkit, without any of the checks or balances we put into *real* internet platforms to assure that there isn't one chokepoint with all of the power. As a result, it's tilted heavily towards winner-take-all economists through accrual of network effects and data advantages. We should not follow this pattern in IETF specifications, whether or not they're associated with the Web. OAUTH-as-deployed might be one good example, but WEBRTC is equally problematic in this regard. WEBTRANS smells like it's primarily going to benefit big platforms who want to control the entire end user experience (and have the resources to exploit it), and let's not even get started about WPACK. Yes, federation is hard. Yes, standards are slow and not as able to respond. Yes, the commercial incentives for silo'd platforms to invest aren't present. However, there's a *huge* push by competition authorities and regulators to find remedies for the concentrations of power in these few hands, and in many minds interoperability standards -- enforced by legal instruments -- are a primary means of getting there. This is potentially game-changing, in terms of the work that's possible to ship here. I wrote a bit more about this recently: https://www.mnot.net/blog/2021/02/18/no-news Cheers, > On 24 Feb 2021, at 4:47 pm, Phillip Hallam-Baker > wrote: > > I am worried by the advice 'use OAUTH' but for a very different reason. > > OAUTH and SAML are both attempts to provide a secure authentication scheme > that works within the very particular and very peculiar environment of Web > browsers. They are schemes that necessarily involve techniques that are > rightly regarded as alchemy if not outright witchcraft. > > That is fine, that is more than fine if you are developing an authentication > scheme for use within Web browsers (or if you are developing whatever SAML > and OAUTH are these days, neither was originally billed as authentication). > But it is completely inappropriate to ever suggest let alone demand that > anyone use a technology whose primary design constraint is to work around the > voodoo of Javascript, URIs, HTTP cookies etc. etc. in an application where > none of those legacy issues apply. > > One of the big problems of IETF is that a lot of people don't think about how > to get their scheme deployed and when they do, their plan is to tie it to > some other group as a boat anchor. Back when we were doing DKIM and SPF we > had to tell certain DNS folk that the fact that almost no DNS Registrars > offered customers the ability to specify new RRTypes was their problem and > was going to remain their problem no matter how loudly they tried to complain > that it should become our problem. > > In the case of OAUTH, there is another problem in that OAUTH really isn't a > very open protocol from the standpoint of the user. I can use my Google or my > Facebook or my Twitter accounts to log in via OAUTH at a large number of > sites. But if I want to use any other OAUTH provider I am completely out of > luck. Or at least I will be until this becomes one of the multifaceted > complaints in the anti-trust hearings coming soon to a capitol hill near you. > And yes, that is a consequence of how the protocol has been deployed, but > that probably not going to get people very far on capitol hill. > > > The Internet is for everyone. The Internet is for end users. > > I am really not that interested in who makes the ingredients except to the > extent that it determines what sort of cake emerges. One of the unexpected > side effects of Web 2.0 has been that it has greatly centralized power in the > hands of a tiny number of individuals. Individuals who are at best > accountable to shareholders, but in the case of some of them, a separate > share class ensures that they are accountable to nobody. In neither case are > the people with power accountable to end users because they are not even > customers, they are the product. > > What I am interested in is the extent to which Internet technologies are > Technologies of Freedom. The question we need to ask ourselves is 'does this > technology increase end user autonomy or increase their reliance on third > parties'. -- Mark Nottingham https://www.mnot.net/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Diversity and Inclusiveness in the IETF
> On 24 Feb 2021, at 2:20 am, Kathleen Moriarty > wrote: [...] > And way back when I was AD, OAuth was by far the most productive working > group I managed. They put out what felt like about 3 documents a meeting for > full publication. I was the AD for 3 years, ending in 2017 when EKR became > an AD. > > There was a bit of management as a result of the number of experts and > varying use cases for their environments, but even with that, OAuth was very > productive. Since your document was 2016, I was likely the AD. Yes, the > meetings had challenges at times, but we worked through it and things got > done. Measuring productivity through the number of documents published is not a good habit for us to get into; it gives incentive to all of the wrong kinds of behaviours. Having some success metrics for our work has come up in the IAB a few times, but we haven't made much progress. Cheers, -- Mark Nottingham https://www.mnot.net/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] FYI - Text resolving DISCUSS issue about Bearer URI Query Parameter method
Thanks, Eran - I was just about to ask about that. On 24/05/2012, at 4:53 PM, Eran Hammer wrote: > I don't care about this either way, but 'explicitly rejected' is an > over-reach. I have not seen the chairs make a consensus call about that, or > even formally ask the list. > > EH > > >> -Original Message- >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf >> Of Mike Jones >> Sent: Wednesday, May 23, 2012 11:49 PM >> To: Julian Reschke >> Cc: Mark Nottingham; oauth@ietf.org >> Subject: Re: [OAUTH-WG] FYI - Text resolving DISCUSS issue about Bearer >> URI Query Parameter method >> >> Yes, putting the query parameter method into an appendix was considered >> and explicitly rejected. Dick Hardt wrote about these issues in the >> discussions that led to this decision, and I'll take the liberty of quoting >> him, as >> I believe he explained it well: >> >> "The reality is that the world is a messy place. Developers hack the >> architecture to accomplish goals not envisioned by the architects. The >> architects can accept the reality of the world, or ignore it and lose their >> relevance. In my opinion, putting the query parameter mechanism into an >> appendix is ignoring the reality of current implementations. Adding language >> to the spec that use of the query parameter is not architecturally ideal, but >> accepts the reality of the current web would be far more preferable." >> >> "Many sites with substantial security expertise (Google, Facebook, LinkedIn, >> Foursquare) have chosen to use the query parameter as opposed to the >> header - both methods have been documented in the drafts since the >> beginning. Clearly from a practical point of view the implementers have >> chosen to use the query parameter. " >> >> "I have read people proposing dropping it from the spec or pushing it to an >> Appendix. I agree that the security issues need to be documented and the >> architectural issues called out. I think dropping it from the spec or >> pushing it >> to an appendix is a disservice to implementers and sends a message that the >> IETF is not in touch with the realities of the web." >> >> -- Mike >> >> -Original Message- >> From: Julian Reschke [mailto:julian.resc...@gmx.de] >> Sent: Wednesday, May 23, 2012 11:36 PM >> To: Mike Jones >> Cc: oauth@ietf.org; Mark Nottingham >> Subject: Re: [OAUTH-WG] FYI - Text resolving DISCUSS issue about Bearer >> URI Query Parameter method >> >> On 2012-05-18 09:15, Julian Reschke wrote: >>> ... >>> Did you consider to *also* move the whole section into an appendix, so >>> that it's status is also reflected by the document structure? >>> >>> Best regards, Julian >> >> Hi, it would be awesome to see feedback on this (it has been mentioned >> during IETF LC multiple times). >> >> Best regards, Julian >> >> >> ___ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth -- Mark Nottingham http://www.mnot.net/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] FYI - Text resolving DISCUSS issue about Bearer URI Query Parameter method
RFCs tend to last longer than 18 months. And many companies. Thanks, On 24/05/2012, at 4:46 PM, David Recordon wrote: > I'm confused by this change given the access_token (or oauth_token) parameter > being the most widely deployed usage of the protocol over the past eighteen > months: > > * https://developers.facebook.com/docs/reference/api/ > * https://developers.google.com/accounts/docs/OAuth2WebServer#callinganapi > * http://msdn.microsoft.com/en-us/library/live/hh243647#response > * http://develop.github.com/p/oauth.html > > --David > > > On Wed, May 23, 2012 at 11:35 PM, Julian Reschke > wrote: > On 2012-05-18 09:15, Julian Reschke wrote: > ... > Did you consider to *also* move the whole section into an appendix, so > that it's status is also reflected by the document structure? > > Best regards, Julian > > Hi, it would be awesome to see feedback on this (it has been mentioned during > IETF LC multiple times). > > > Best regards, Julian > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Mark Nottingham http://www.mnot.net/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard
My comments were made in: http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03805.html Most of them (excepting the nits) haven't been addressed in the drafts. Regards, Begin forwarded message: > Subject: [OAUTH-WG] Last Call: (The OAuth > 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard > Date: Mon, 23 Jan 2012 07:46:43 -0800 > From: The IESG > Reply-To: i...@ietf.org > To: IETF-Announce > CC: oauth@ietf.org > > > The IESG has received a request from the Web Authorization Protocol WG > (oauth) to consider the following document: > - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > i...@ietf.org mailing lists by 2012-02-06. Exceptionally, comments may be > sent to i...@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This specification describes how to use bearer tokens in HTTP > requests to access OAuth 2.0 protected resources. Any party in > possession of a bearer token (a "bearer") can use it to get access to > the associated resources (without demonstrating possession of a > cryptographic key). To prevent misuse, bearer tokens need to be > protected from disclosure in storage and in transport. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ > > > No IPR declarations have been submitted directly on this I-D. > -- Mark Nottingham http://www.mnot.net/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OK to post OAuth Bearer draft 15?
uot;realm" parameter is > restricted to quoted-string was a bad design choice not to be > repeated for new parameters. > > First, it's my understanding that this text was added between -16 and -17 > explicitly to try to force a change the definitions used in the Bearer spec. > While this seems heavy-handed, be that as it may. Assuming the > specification remains as-is, I think there are two code reusability cases to > consider: > > Recipient Case: Recipients are able to use code capable of parsing both > token and quoted-string syntax to parse fields that may only contain quoted > string syntax. Thus, the rationale for this requirement given in P7 is > actually incorrect; recipients *can* use a generic parser that applies to all > authentication schemes. (Perhaps P7 should be corrected?) There is no > code-reuse problem for recipients. > > Producer Case: I will grant that it is possible for generic parameter > producer code to exist that does not give the caller control over how the > parameter is serialized. If such code is used, it would be possible for a > parameter value such as "xyz" to be erroneously serialized as xyz, thus > creating an interoperability problem. Note however, that serialization of > the HTTP-defined realm parameter MUST occur using quoted-string > serialization. Thus, in practice, it would seem that generic frameworks > still need to enable callers to control the serialization formats of specific > parameters. Hence, I doubt that this problem-in-theory is actually a > problem-in-practice. I'd be interested in data points from the working group > about whether HTTP frameworks they use would have his problem in practice or > not. > > It seems that there are two possible resolutions to this issue: > > 1. Change the spec to allow both quoted-string and token serialization for > these parameters. > > 2. Leave the specification as-is. > > I'd like to hear working group opinions on which of these potential > resolutions members support. > > ON SUITABILITY AS A PROXY AUTHENTICATION SCHEME: > > Could someone who is a member of ietf-http...@w3.org volunteer to ask that > list whether they would like to make any review comments on > http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-15 as to its > suitability for use as a proxy authentication scheme (and to cc: me when you > ask the question)? I'm not a member of this list. I've done that. Cheers, > > Thanks all, > -- Mike > > -Original Message- > From: Mark Nottingham [mailto:m...@mnot.net] > Sent: Wednesday, December 14, 2011 6:37 PM > To: Mike Jones > Cc: Stephen Farrell; Hannes Tschofenig; Peter Saint-Andre; Barry Leiba; OAuth > WG > Subject: Re: OK to post OAuth Bearer draft 15? > > Hi Mike - > > It's not my function to object (or not) to the publication of the draft; I > merely provided the APPS review, which will be considered by the responsible > AD (like all other Last Call comments), and potentially the IESG. > > If you're asking whether my concerns have been addressed, see some specifics > below. > > Regards, > > > On 15/12/2011, at 1:13 PM, Mike Jones wrote: > >> Mark, Stephen, Hannes, and Barry, >> >> Any objections to posting the updated Bearer draft incorporating the results >> of the APPS Area review and the TLS requirements? >> >>-- Mike >> >> From: Mike Jones >> Sent: Monday, December 12, 2011 8:51 AM >> To: Mark Nottingham; 'Stephen Farrell'; oauth@ietf.org >> Subject: RE: [OAUTH-WG] FW: [apps-discuss] APPS Area review of >> draft-ietf-oauth-v2-bearer-14 >> >> Thanks for the detailed review, Mark. >> >> Preliminary draft 15 of the OAuth Bearer specification is attached. It >> resolves the form encoding issues raised by Julian Reschke in the manner >> discussed at the working group meeting in Taipei, incorporates the consensus >> text on TLS version requirements, and contains several improvements >> suggested by Mark Nottingham during APPS area review. >> >> Mark, comments on all your proposed changes follow below: >> >>> * Section 2.3 URI Query Parameter >>> >>> This section effectively reserves a URI query parameter for the draft's >>> use. This should not be done lightly, since this would be a precedent for >>> the IETF encroaching upon a server's URIs (done previously in RFC5785, but >>> in a much more limited fashion, as a ta
Re: [OAUTH-WG] OK to post OAuth Bearer draft 15?
Hi Mike -
It's not my function to object (or not) to the publication of the draft; I
merely provided the APPS review, which will be considered by the responsible AD
(like all other Last Call comments), and potentially the IESG.
If you're asking whether my concerns have been addressed, see some specifics
below.
Regards,
On 15/12/2011, at 1:13 PM, Mike Jones wrote:
> Mark, Stephen, Hannes, and Barry,
>
> Any objections to posting the updated Bearer draft incorporating the results
> of the APPS Area review and the TLS requirements?
>
> -- Mike
>
> From: Mike Jones
> Sent: Monday, December 12, 2011 8:51 AM
> To: Mark Nottingham; 'Stephen Farrell'; oauth@ietf.org
> Subject: RE: [OAUTH-WG] FW: [apps-discuss] APPS Area review of
> draft-ietf-oauth-v2-bearer-14
>
> Thanks for the detailed review, Mark.
>
> Preliminary draft 15 of the OAuth Bearer specification is attached. It
> resolves the form encoding issues raised by Julian Reschke in the manner
> discussed at the working group meeting in Taipei, incorporates the consensus
> text on TLS version requirements, and contains several improvements suggested
> by Mark Nottingham during APPS area review.
>
> Mark, comments on all your proposed changes follow below:
>
>> * Section 2.3 URI Query Parameter
>>
>> This section effectively reserves a URI query parameter for the draft's use.
>> This should not be done lightly, since this would be a precedent for the
>> IETF encroaching upon a server's URIs (done previously in RFC5785, but in a
>> much more limited fashion, as a tactic to prevent further, uncontrolled
>> encroachment).
>>
>> Given that the draft already discourages the use of this mechanism, I'd
>> recommend dropping it altogether. If the Working Group wishes it to remain,
>> this issues should be vetted both through the APPS area and the W3C liaison.
>>
>> (The same criticism could be leveled at Section 2.2 Form-Encoded Body
>> Parameter, but that at least isn't surfaced in an identifier)
>>
> There are some contexts, especially limited browsers and/or development
> environments
What does "developmental environments" mean here?
> , where query parameters are usable but the other methods are not. Thus, the
> query parameter method must be retained. Also, Justin Richter’s comments
> describing the value to him of the query parameter method are pertinent: “A
> URL with all parameters including authorization is a powerful artifact which
> can be passed around between systems as a unit”.
>
> As to using a standard parameter name, this is essential for interoperability.
I find it hard to believe that you could not find or design a mechanism to
discover a URI.
> It is not “reserved” in any contexts other than when the Bearer spec is
> employed, which is a voluntary act by both parties. Thus, this poses no
> undue burdens or namespace restrictions on implementations in practice.
>
> Finally, you’ll find that OAuth 1.0 [RFC 5849] similarly defined, not one,
> but two standard query parameter values: oauth_token and oauth_verifier. As
> this didn’t cause any problems in practice then, I’m sure that defining an
> access_token parameter within the Bearer spec for interoperability purposes
> won’t cause a problem either.
The fact that a non-standards-track document did something that's potentially
harmful doesn't make it OK. Saying that problems won't occur based upon such
short-term implementation experience with this type of issue is ludicrous; the
nature of the issue is long-term encroachment and setting precedent.
>> * Section 3 The WWW-Authenticate Response Header Field
>>
>> The draft references the quoted-string ABNF from HTTP, but changes its
>> processing in a later paragraph:
>>
>> """In all these cases, no character quoting will occur, as senders are
>> prohibited from using the %5C ('\') character."""
>>
>> This is at best surprising (as many readers will reasonably surmise that
>> using the quoted-string ABNF implies that the same code can be used).
>> Please either use quoted-string as defined (i.e., with escaping).
>>
> This parameter definition was a result of significant working group
> discussion and reflects a solid consensus position. Using the quoted string
> BNF makes it clear, per Julian Reschke’s suggestions, that generic parameter
> parsing code can be safely used. Whereas prohibiting the use of backslash
> quoting by senders also makes it clear that custom implementations can
> dire
Re: [OAUTH-WG] [apps-discuss] HTTP MAC Authentication Scheme
It sounds like it's specifying *almost* the same thing, but in a different way. Why is there friction? Is it fashion, NIH or something more substantial? Cheers, On 20/11/2011, at 4:08 AM, Eran Hammer-Lahav wrote: > > >> -Original Message----- >> From: Mark Nottingham [mailto:m...@mnot.net] >> Sent: Tuesday, May 31, 2011 4:57 PM > >> The "normalized request string" contains the request-URI and values >> extracted from the Host header. Be aware that intermediaries can and do >> change these; e.g., they may change an absolute URI to a relative URI in the >> request-line, without affecting the semantics of the request. See [1] for >> details (it covers other problematic conditions too). >> >> It would be more robust to calculate an effective request URI, as in [2]. >> [2] http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14#section-4.3 > > Using the effective request URI has proved to be a significant point of > friction in OAuth 1.0. I would rather note that intermediaries can change the > request URI and that the server must reverse those changes based on what the > values should have been if they were received from the client directly. > > EHL -- Mark Nottingham http://www.mnot.net/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [apps-discuss] [http-state] HTTP MAC Authentication Scheme
This is an interesting discussion, but a bit much to cross-post to four different lists. I've set followups to apps-discuss (since it's the most general). Cheers, On 08/06/2011, at 1:17 PM, Nico Williams wrote: > On Tue, Jun 7, 2011 at 9:40 PM, William J. Mills wrote: >> It is possible to implement decent security with MAC, it is also possible to > > Not as specified. See earlier posts regarding active attacks. > >> screw it up. It is far more difficult (impossible?) to implement decent >> security with cookies over HTTP. > > Assuming well-behaved browsers that understand the distinction between > "secure" and non-secure cookies, and assuming that active attacks are > often no more difficult than passive attacks, what does MAC without > TLS add that cookies don't provide? > > Nico > -- > ___ > apps-discuss mailing list > apps-disc...@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [apps-discuss] HTTP MAC Authentication Scheme
On 03/06/2011, at 1:44 AM, Eran Hammer-Lahav wrote: > > >> -Original Message----- >> From: Mark Nottingham [mailto:m...@mnot.net] >> Sent: Wednesday, June 01, 2011 5:16 PM >> To: Eran Hammer-Lahav >> Cc: apps-disc...@ietf.org; Ben Adida; http-st...@ietf.org; OAuth WG; >> 'Adam Barth (a...@adambarth.com)'; HTTP Working Group >> Subject: Re: [apps-discuss] HTTP MAC Authentication Scheme >> >> >> On 02/06/2011, at 1:00 AM, Eran Hammer-Lahav wrote: >> >>> This was suggested before, but are there really attack vectors for this? >> >> If not having a current, working attack to demonstrate is a valid way to >> shrug >> off a security concern, that's great; it'll be a useful approach to many of >> the >> discussions I have. :) > > No, but its valid as long as it is fully documented. We're not going to solve > everything. > >>> The problem is that content-type is a pretty flexible header, which means >> normalization of the header will be required (case, parameter order, white >> space, etc.). >> >> The media type is the important part, and it's much more constrained. > > So include just the: > > type "/" subtype > > forced to lowercase? Think so. > >> >>> I would argue that if you are using MAC with body hash and an attacker >> changing the media type can cause harm, you should use additional methods >> to secure the content-type (such as making the body self-describing). >> >> >> That seems like a step backwards, considering all of the work that Adam has >> put into limiting the use of sniffing. > > I wasn't suggesting sniffing. > > EHL > >> Cheers, >> >> -- >> Mark Nottingham http://www.mnot.net/ >> >> > -- Mark Nottingham http://www.mnot.net/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [apps-discuss] HTTP MAC Authentication Scheme
On 02/06/2011, at 1:00 AM, Eran Hammer-Lahav wrote: > This was suggested before, but are there really attack vectors for this? If not having a current, working attack to demonstrate is a valid way to shrug off a security concern, that's great; it'll be a useful approach to many of the discussions I have. :) > The problem is that content-type is a pretty flexible header, which means > normalization of the header will be required (case, parameter order, white > space, etc.). The media type is the important part, and it's much more constrained. > I would argue that if you are using MAC with body hash and an attacker > changing the media type can cause harm, you should use additional methods to > secure the content-type (such as making the body self-describing). That seems like a step backwards, considering all of the work that Adam has put into limiting the use of sniffing. Cheers, -- Mark Nottingham http://www.mnot.net/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [apps-discuss] HTTP MAC Authentication Scheme
Hi, Reading draft -05. The "normalized request string" contains the request-URI and values extracted from the Host header. Be aware that intermediaries can and do change these; e.g., they may change an absolute URI to a relative URI in the request-line, without affecting the semantics of the request. See [1] for details (it covers other problematic conditions too). It would be more robust to calculate an effective request URI, as in [2]. Also, if you include a hash of the request body, you really need to include a hash of the body media type. Generally, I think that people can and will want to include other headers; just because *some* developers can't get this right doesn't mean we should preclude *all* developers from doing it. It'd be really nice to see this either leverage DOSETA [3][4], or at least offer a clean transition path to it. Regards, 1. http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14#section-4.1.2 2. http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14#section-4.3 3. http://tools.ietf.org/html/draft-crocker-dkim-doseta-00 4. http://tools.ietf.org/html/draft-crocker-doseta-base-02 On 10/05/2011, at 5:22 AM, Eran Hammer-Lahav wrote: > (Please discuss this draft on the Apps-Discuss > mailing list) > > http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token > > The draft includes: > > * An HTTP authentication scheme using a MAC algorithm to authenticate > requests (via a pre-arranged MAC key). > * An extension to the Set-Cookie header, providing a method for associating a > MAC key with a session cookie. > * An OAuth 2.0 binding, providing a method of returning MAC credentials as an > access token. > > Some background: OAuth 1.0 introduced an HTTP authentication scheme using > HMAC for authenticating an HTTP request with partial cryptographic protection > of the HTTP request (namely, the request URI, host, and port). The OAuth 1.0 > scheme was designed for delegation-based use cases, but is widely “abused” > for simple client-server authentication (the poorly named ‘two-legged’ use > case). This functionality has been separated from OAuth 2.0 and has been > reintroduced as a standalone, generally applicable HTTP authentication scheme > called MAC. > > Comments and feedback is greatly appreciated. > > EHL > ___ > apps-discuss mailing list > apps-disc...@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] BCP for returning HTTP Authentication (2617) Error Status (questions from the OAuth WG)
My .02 - On 10/05/2011, at 2:49 AM, Eran Hammer-Lahav wrote: > The OAuth working group has defined an authorization protocol [1] for > delegating access to protected resources. Once access has been authorized, > the client is issued a set of token credentials which are uses to make > authenticated HTTP requests. To accomplish that, the OAuth working group has > proposed two new HTTP authentication schemes: Bearer [2] and MAC [3]. > > The working group has been debating the issue of what's the best current > practice for returning an error status in an HTTP authentication scheme. The > Basic and Digest schemes do not specify the error condition and simply return > a 401 response with a new challenge. The MAC proposal follows this pattern. > > The Bearer scheme proposal is taking a more active approach, defining an > 'error' response attribute for use with the WWW-Authenticate header and an > error code registry to go along. The parameter and registry (especially the > registry) are meant for reuse by other HTTP authentication schemes. At the > moment, the three error conditions proposed by the Bearer draft are: invalid > request, invalid token, and insufficient scope (which arguably is better > suited using a 403 response with or without a new challenge). > > While these error codes arguably do not provide an immediate actionable value > (pending the help of future discovery specifications), the attribute and > registry propose a forward-looking solution for when clients will be able to > automatically resolve such issues (with the help of future discovery > specifications). > > The OAuth WG is seeking guidance on the following questions: > > 1. Should the WG define a general purpose method for returning errors with a > 401 WWW-Authenticate headers, including a cross-scheme error code registry? I don't have strong feelings about whether or not it's a good idea overall. However, I tend to think that if it's intended for more than one scheme, it'd make more sense to a) make it a separate header, much like Authentication-Info for successful responses, and b) also note that it's a good idea to put human-friendly information in the response body (e.g., in HTML). Making it a separate header not only avoids collisions (largely theoretical at this stage), it also doesn't put too much information into WWW-Authenticate (which has never had the cleanest syntax), avoiding potential parsing issues, etc. > If you answered yes to #1: > > 2. Should the WG apply this to all new HTTP authentication schemes > (currently, MAC, but potentially more)? What does "apply" mean here? Do you just want to allow people to use the same error codes with other auth schemes if they want to, knowing that most existing software won't use it? > 3. Should this new error attribute and registry be part of the main OAuth 2.0 > specification, part of one of the upcoming schemes (for use with other > schemes), or standalone? If you really want people to use it for other schemes, it needs to be a separate spec; no matter how much you say otherwise, folks assume that if it's part of a bigger spec, it's inseparable. > If you answered no to #1: > > 4. Should the Bearer draft retain the attribute and registry for its own > scheme-specific needs? Not sure how that's relevant here... Cheers, -- Mark Nottingham http://www.mnot.net/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Returning HTTP 200 on Error for JSONP
How fortuitous: http://blogs.msdn.com/b/ieinternals/archive/2010/08/19/http-error-pages-in-internet-explorer.aspx On 19/08/2010, at 8:47 AM, Mark Nottingham wrote: > See: > http://support.microsoft.com/kb/294807 > > > On 19/08/2010, at 1:55 AM, Brian Eaton wrote: > >> On Tue, Aug 17, 2010 at 11:36 PM, Mark Nottingham wrote: >>>> The other reason people get funny with these status codes has to do >>>> with browser behavior. Sometimes browsers react in funny ways to >>>> funny HTTP status codes. To be on the safe side, developers tend to >>>> return an HTTP 200 with whatever they want the user to see. >>> >>> Can you give concrete examples, please? What browsers do what exactly, >>> under what circumstances? >> >> Here's a well-known example: >> http://malektips.com/internet-explorer-8-disable-friendly-error-messages.html. >> >> Fuzzier stuff is in handling of things like WWW-Authenticate headers >> on HTTP 200 responses, or 401s with unknown authorization challenges. > > > -- > Mark Nottingham http://www.mnot.net/ > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- Mark Nottingham http://www.mnot.net/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Returning HTTP 200 on Error for JSONP
See: http://support.microsoft.com/kb/294807 On 19/08/2010, at 1:55 AM, Brian Eaton wrote: > On Tue, Aug 17, 2010 at 11:36 PM, Mark Nottingham wrote: >>> The other reason people get funny with these status codes has to do >>> with browser behavior. Sometimes browsers react in funny ways to >>> funny HTTP status codes. To be on the safe side, developers tend to >>> return an HTTP 200 with whatever they want the user to see. >> >> Can you give concrete examples, please? What browsers do what exactly, under >> what circumstances? > > Here's a well-known example: > http://malektips.com/internet-explorer-8-disable-friendly-error-messages.html. > > Fuzzier stuff is in handling of things like WWW-Authenticate headers > on HTTP 200 responses, or 401s with unknown authorization challenges. -- Mark Nottingham http://www.mnot.net/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Returning HTTP 200 on Error for JSONP
On 18/08/2010, at 3:57 PM, Brian Eaton wrote: > On Tue, Aug 17, 2010 at 7:33 PM, John Panzer wrote: >> Is there any legit reason other than jsonp specifically? > > Protected resource authors are slack and are not going to read the > spec. That might not be a great reason, but it's not a bad one > either. > > The other reason people get funny with these status codes has to do > with browser behavior. Sometimes browsers react in funny ways to > funny HTTP status codes. To be on the safe side, developers tend to > return an HTTP 200 with whatever they want the user to see. Can you give concrete examples, please? What browsers do what exactly, under what circumstances? > The last reason is that servers fail, and instead of returning the > error they meant to return they serve up a bit of static HTML that > says, more or less, "Whoa. That sucked." > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- Mark Nottingham http://www.mnot.net/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Returning HTTP 200 on Error for JSONP
h you can grab with
>>>>>>
>>>>>> function jsonp_cb(response, code, status) {
>>>>>> }
>>>>>>
>>>>>> or ignore it with
>>>>>>
>>>>>> function jsonp_cb(response) {
>>>>>> }
>>>>>>
>>>>>> But all of this is outside of the spec. I just want to make sure the
>>>>>> spec says that the HTTP status code can send as 200 if the server+client
>>>>>> need it for errors.
>>>>>>
>>>>>>
>>>>>> I think this can be achieved in two ways: (a) either the client tells
>>>>>> the server using a parameter or (b) the server always responds with
>>>>>> status code 200 in some cases. From my understanding, status code 200 is
>>>>>> relevant for requests following the rules of section 5.1.2 only. So my
>>>>>> sugesstion would be to go with option (b) and modify the spec to always
>>>>>> return status code 200 for such requests. This keeps the spec simpler
>>>>>> and preserves the behavior of requests--
>> --
>> John Panzer / Google
>> jpan...@google.com / abstractioneer.org / @jpanzer
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>
> --
> --
> John Panzer / Google
> jpan...@google.com / abstractioneer.org / @jpanzer
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
--
Mark Nottingham http://www.mnot.net/
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
