"Dynamically declaring," in what sense? Where are those mechanisms documented?
Many of them are documented in draft-ietf-oauth-dyn-reg. One profile (an outer doll :)) that enables fully interoperable implementations is documented in draft-hardjono-oauth-umacore. It uses the "http://docs.kantarainitiative.org/uma/scopes/prot.json"; scope value as its "tagged field" value. Another related profile that enables fully interoperable implementations is documented in http://openid.net/specs/openid-connect-messages-1_0.html. It uses the "openid" scope value as its "tagged field" value, per http://openid.net/specs/openid-connect-messages-1_0.html#scopes. I know that Dick Hardt has another profile that's using the JWT Assertion Profile for a BC Government identity project. I know of ones used inside of enterprises and at cloud services as well. -- Mike From: barryleiba.mailing.li...@gmail.com [mailto:barryleiba.mailing.li...@gmail.com] On Behalf Of Barry Leiba Sent: Monday, February 18, 2013 10:37 AM To: Mike Jones Cc: Barry Leiba; oauth-cha...@tools.ietf.org; oauth@ietf.org Subject: Re: [OAUTH-WG] oauth assertions plan I'll get to John's message later, after I digest it more. I can reply to this one now. please explain how you and I can each write applications to that? You can write applications to that by having the profile chain end, and with the contents of the Audience field being completely specified somewhere in the profile chain being used. In order for that to work, we have to know ("we" being both sides of the protocol, and also "we" being different implementors of similar applications) what profile to use. I am proposing that there must be a way for someone writing an application to know what to use in these fields that will work with your application (or will work with a server in the same way as your application does, or whatever) *without* having to go to the documentation of your application to figure it out. I agree with what I think you mean, but possibly not with how you're saying it. Using the TCP analogy again, in fact, to understand the contents of the TCP stream for port 25, one has to go to the documentation of the application communicating on port 25. In this case, that documentation is RFC 821 and its successors. Yeh, here's where we're disconnected. One does NOT have to go to the documentation of the application at all. One has to go to the specification of SMTP. But one needn't know *anything* about any other implementations of SMTP: everything you need is in the SMTP spec (including that it runs on port 25). If there were a similar thing here, I'd be happy. But if there's a similar thing here, I don't see it. I'll also observe that the working group is also working on a specification that enables an OAuth client to dynamically register itself with the Authorization Server (draft-ietf-oauth-dyn-reg) and that that registration does declare information about what profile is being used, as John Bradley pointed out in his response. That's a key piece of the whole solution to enable interoperable implementations. It sounds like it is a key piece, and in that case I think that document needs to come forward along with (or before) the ones that depend on it for interoperability. Absent something like that, we can't evaluate whether it's possible to write interoperable implementations of this spec. We already do have mechanisms for dynamically declaring what profile is being used, and we are using them. "Dynamically declaring," in what sense? Where are those mechanisms documented? I agree with Stephen that we should let this conversation run for a while to make sure everyone comes to a common understanding, but ultimately, I hope that you'll withdraw your DISCUSS, because, in fact, interoperable implementations can be written by reading the specs used alone. I still don't see that that's true (how did those interoperable implementations resolve the incompletely specified bits?), but, in any case, don't obsess over the DISCUSS ballot, because it no longer matters: Stephen has returned the document to the working group, and when it comes back to IESG Evaluation again I'm sure Stephen will issue a new ballot and we'll start the process from a clean slate. Barry
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
